Lo stile di codifica nelle organizzazioni è facoltativo?

Per quanto posso dire, l'affermazione che ti ha confuso è un compromesso pragmatico fatto per permettere alle linee guida di servire il più vasto pubblico possibile. A seconda del tuo contesto specifico (più su quello sotto) potresti avere un'opzione per regolarlo e fare un uso più efficiente delle linee guida.

Vedete, le linee guida si riferiscono a "forti obiezioni personali" come mezzo per giustificare la violazione. Tali obiezioni non sono qualcosa da ignorare leggermente, specialmente se queste provengono da sviluppatori esperti.

Queste obiezioni possono essere sbagliate, attenzione, ma (e questo è molto BIG BUT) possono anche indicare che una particolare regola è sbagliata - in generale o nel contesto del progetto specifico ( un esempio di errore di regola è un requisito per fornire una registrazione dettagliata nel codice critico delle prestazioni).

Penso che qualsiasi guida di stile ragionevole dovrebbe prendere in considerazione quanto sopra e cercare di soddisfare una possibile necessità di adattarsi. Ora, se la guida che ti ha confuso era indirizzata solo a team maturi con processi e ambiente efficienti e fluidi, potrebbe essere dichiarata molto meno ambiguamente, ad esempio in questo modo:

The rules should be followed strictly, unless a challenge is raised against them - in which case challenged rule should stay ignored until this is resolved - either by rejecting the challenge or by accepting it and adjusting the rules to fit.

Potresti apprezzare meglio quanto sopra e potresti desiderare che sia così ovunque, per tutti, ma guarda più da vicino la parte "la sfida è sollevata / rimani ignorata / aggiustata" e chiediti come può essere implementata. Chiediti quanto tempo ci vorrà a seconda del progetto e della squadra. Se ci vuole un'ora, è accettabile? Cosa succede se ci vuole un giorno, una settimana o ... un mese?

Vedete, l'approccio sfidante e ignorato fino a quando non risolto potrebbe aprire una larga porta agli abusi se fosse presentato come una guida per qualsiasi progetto. "Sì, sì, ti ascoltiamo, facciamolo come dice la guida.In primo luogo, compila questo modulo di richiesta e ottieni le approvazioni dell'amministratore delegato / CFO / CTO, aspettati che ci vorrà una settimana o due. i nostri controlli del codice, che potrebbero richiedere un'altra settimana o due. Nel frattempo, assicurati che il tuo codice critico delle prestazioni vomiti le dichiarazioni di registrazione correttamente formattate su ogni spostamento del registro. "

Non riesco a leggere le menti degli autori delle guide, ma sembra ragionevole presumere che volessero evitare di usarlo per giustificare un pasticcio come descritto sopra. Da questo punto di vista è semplicemente più sicuro affermare chiaramente che la guida non presuppone alcuna applicazione - in questo modo, per quanto maldestro, consente comunque di essere utilizzabile per una gamma arbitrariamente ampia di team e progetti. Probabilmente ci si aspetta che un assegno così ampio lasci ai team più maturi ed efficienti l'opportunità di restringerlo ragionevolmente senza danneggiare la produttività degli sviluppatori.

Applicato al tuo caso specifico, scrivendo il documento di stile di codifica per il tuo team e fallendo la revisione del codice se lo stile non corrisponde - Penso che devi capire quanto tempo ci vorrà affinché gli sviluppatori sfidino una particolare regola, ottieni ignorato, risolto e modificato o ripristinato in base alla risoluzione.

Se trovi un modo per far funzionare questo processo senza introdurre molti ostacoli nel tuo flusso di lavoro di sviluppo, allora vale la pena considerare un approccio di risoluzione / risoluzione formale e facile da tracciare invece del caotico "violare se piangi abbastanza strong".

Come nota a margine, vorrei rispondere a ciò che hai scritto in un altro commento ," Supponiamo che lo stile di codifica sia l'ideale, e se così non fosse, ecc. "

Questa è un'assunzione pericolosa, davvero. Mi sono rotto il naso (due volte! In un unico progetto !, dove avevo una vasta esperienza e immaginavo di sapere tutto su di esso, vai a capire) e ti consiglio vivamente di lasciar perdere. È più sicuro assumere che la guida allo stile possa avere degli errori e fare uno sforzo per pensare a cosa fare nel caso in cui tali errori vengano scoperti.

Consentire alle persone di ignorare gli stili di codifica a causa della preferenza personale è una cattiva idea.

La citazione nella tua domanda sembra consentire a qualsiasi sviluppatore di dire semplicemente "Non userò questo stile perché non mi piace."

Questo va contro l'intero punto, che è far sì che tutti nel team facciano le cose allo stesso modo per coerenza e leggibilità.

Sono d'accordo sul fatto che un documento di stile con una simile affermazione sia probabilmente inutile.

Tuttavia, è consigliabile una certa flessibilità nell'aderire alle linee guida di stile:

• Seguire pedissequamente una linea guida potrebbe impedire il modo migliore di scrivere un particolare pezzo di codice . Gli sviluppatori dovrebbero essere in grado di ignorare la linea guida e di dimostrare che ciò che hanno fatto è il modo migliore e più leggibile per realizzare qualcosa in questo caso.
• Lavorare con il codice legacy può richiedere flessibilità. Probabilmente non è un buon uso del tuo tempo per ridefinire una grande base di codici esistente. Se riscrivi in modo significativo una particolare sezione, puoi riformattarla nello stile preferito. Tuttavia, se si apportano piccole modifiche, potrebbe essere preferibile utilizzare lo stile esistente del codice.
• Ignorare su ogni piccola violazione della guida allo stile non è un buon uso del tempo. La revisione del codice è un buon momento per evidenziare qualsiasi codice che sia significativamente fuori linea rispetto allo stile del team. Tuttavia, catturare e correggere piccoli "errori" di stile è probabile che diventi un lavoro impegnato che si concentra sulla cosa sbagliata. Certo, fallire la revisione del codice se lo stile è stato palesemente ignorato. Ma non mi piace l'idea di far funzionare un analizzatore e di evidenziare ogni parentesi o rientranza fuori posto, non importa se qualcuno non riesce su questa base.

In conclusione: concedi flessibilità nell'aderire alle linee guida di stile, al fine di soddisfare al meglio le esigenze della tua squadra, ma non per motivi arbitrari come le preferenze personali.

Lo stile di codifica e le guide di stile esistono per rendere il codice più leggibile. E la leggibilità esiste per aiutare con la complessità.

Quindi alla fine se violare o meno (lo definirei adattissimo) lo stile di codifica per soddisfare i tuoi bisogni organizzativi si riduce a quanto aiuta a rendere le cose comprensibili.

Ricorda, tutto, e sottolineo, TUTTO, dalla programmazione OO ai paradigmi funzionali, a vari modelli di concorrenza, esiste per il solo motivo di aiutare le persone ad affrontare la complessità.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler, 2008

Is coding style in organizations an optional thing?

Le organizzazioni scelgono di avere stili di codifica: non è necessario avere il primo.

Quindi la citazione che stai leggendo affronta il problema più grande che vedo riguardo allo "stile" di codifica e agli "hacker" superstar reali: porti a bordo un nuovo ragazzo e lui scrive codice che farà cadere gli zombi e renderà quei vecchi server tuoi urlando velocemente ... ma il suo stile di codifica è diverso dal tuo "stile organizzativo accettato". Si rifiuta di cambiare e il processo per far sì che tutti si conformino a il suo stile particolare sarà lungo e costoso. E adesso?

La maggior parte dei super hacker che conosco sono dotati di ego tanto grandi quanto le loro abilità e vogliono che l'organizzazione si adatti a loro , non viceversa. Quindi, forse il tuo standard di stile di codifica dovrebbe essere più simile a una guida di stile di codifica in modo che tu possa lasciare che questo killer hacker continui a scrivere codice veloce e sorprendente con qualche devianza stilistica, ma assicurati che tutti gli altri capiscano che fino a quando non raggiungono il suo epico stato di hacker, devono seguire le regole (o persino aiutare a ripulire dopo di lui).

Ovviamente, questo è un incubo gestionale, ma la gestione delle persone tecnologiche in generale è un po 'come gregge di gatti. Quindi molte aziende hanno "linee guida di stile" e non "standard di stile". E le build non falliscono e le revisioni del codice non falliscono automaticamente a causa delle violazioni di stile in tutte le aziende. Puoi decidere il problema di gestione che vuoi avere: consentire gli hacker superstar e avere "linee guida" o perdere le superstar e avere uno stile di codice più coerente.

So, am I misunderstanding something from this document and the quote at the top of this question? Can people really just ignore coding style?

Dipende.

Il posto in cui sono attualmente non ha una guida di stile e non è un grosso problema. Esistono alcune leggere variazioni tra i programmatori, ma non tanto da incidere sulla leggibilità, sulla rilevabilità o sulla coerenza in alcun modo significativo. E abbiamo un gruppo abbastanza grande e una cultura abbastanza strong per far sì che ogni nuovo membro del team ricada in linea (o altro).

Nelle società precedenti, stavamo crescendo rapidamente e avevamo alcune persone che non conoscevano la lingua e le sue espressioni idiomatiche. In quella compagnia, l'afflusso di persone significava che non esisteva una cultura che imponeva una buona scrittura. E le persone nuove nella lingua volevano che ci fosse un sacco di cose da sistemare. Lì i controllori di stile automatici erano il modo più efficiente per effettuare le regolazioni, e una vera guida scritta era il modo migliore per addestrare le nuove persone alle nostre aspettative.

Personalmente, non mi interessa molto le guide di stile e mi prendo ancora meno attenzione per l'applicazione automatica dello stile. Se la persona non riesce nemmeno a prendere gli idiomi di base, perché li impieghi come programmatori? E se sono così brutti giocatori di squadra che scriveranno continuamente codice che gli altri trovano difficile da lavorare, perché li stai impiegando affatto?

Questo è più uno stratagemma psicologico piuttosto che un'interpretazione letterale del modo migliore per gestire gli stili di codifica. Rende la squadra / azienda / manager / leader meno autoritaria. Mi concentrerei maggiormente su eccezioni situazionali invece che personali. Indipendentemente dal documento di programmazione, l'obiettivo è rendere le cose facili da leggere. Il codice confuso dovrebbe essere indirizzato e modificato se ritenuto necessario. Ci sono molti strumenti per prendersi cura delle piccole cose noiose, quindi usale.

Ci sono eccezioni a ogni regola. Dare alla gente "un po 'di spazio di manovra". Meno tutti sono coinvolti nell'accettare le regole dello stile di codifica (Welcome new guy.), Più sono inclini a voler contrattaccare. Molte cose sono in bianco e nero, ma alcune sono aperte all'interpretazione.

L'obiettivo dovrebbe essere quello di coinvolgere tutti nello spirito delle linee guida di codifica invece di litigare su ogni piccolo dettaglio e interpretazione.

Sì, arriverà il momento in cui il documento di stile di codifica non ha senso da utilizzare e gli sviluppatori professionisti e adulti dovrebbero poter conoscere la differenza.

In base alle tue modifiche, il tuo obiettivo è raggiungere l'obiettivo giusto.

Ci sono molti vantaggi nell'utilizzare una guida di stile, ma i due più importanti a mio parere, sono la leggibilità del codice tra i membri del team e la mancanza di commit "stupidi" (come solo lo spazio bianco, o linee extra e simili) .

Per raggiungere il tuo obiettivo, la tua guida di stile scelta (o creata) dovrebbe essere semplice e facile da rispettare. Cerca di concentrarti davvero su ciò di cui hai bisogno. A nessuno piace dover tornare indietro e riscrivere un'enorme quantità di codice solo per rendere felice un linter. Ma potrebbero ancora esserci dei benefici.

Assicurati che i membri del tuo team approvino la guida allo stile. La tua intenzione di tenerli, assicurarsi che siano d'accordo o sarà una lotta eterna.

Assicurati che le violazioni di stile siano un "avvertimento" e non un "errore", lascia che un essere umano decida se la violazione incontra un errore. La ragione di questo è semplice. Credo in un flusso di lavoro semplice. Se da qualche parte nella fase di "test" si verifica un "errore", non è possibile spingere alla produzione. Io uso è come una sicurezza. Anche le hot fix devono passare attraverso una fase di test (anche se più breve). Puoi davvero affermare che non imposterai la correzione di bachi critici alla produzione perché qualcuno ha usato un "invece di un"? Che ne dici di usare un ciclo for invece di uno ciascuno? E se un ciclo for ha qualche miglioramento rispetto a ciascuno? sono le decisioni che una macchina (linter) non può fare, quindi assicurati di avere un umano, giudica l'avvertimento, e non la macchina lancia un fallimento.

Per ignorare la guida di stile, devi giudicarla caso per caso. Assicurati che la "deviazione" abbia una vera ragione. Verranno. Il lavoro dei revisori è di assicurarsi che ci sia una buona ragione per la deviazione e non una banalità.

Ho lottato per anni con le linee guida sullo stile del codice, come molti altri hanno su questo forum. Ciò include sia le guide allo stile di combattimento che trovo aborrite, sia il tentativo di incoraggiare gli altri a utilizzare le guide di stile per tenere a freno il loro stile in modo che possa essere più leggibile nel suo complesso.

La società beneficia di uno standard di codifica comune. Ci sono molte cose importanti da considerare nello sviluppo di software per un'azienda, come il modo in cui formeremo nuovi sviluppatori per raccogliere il codice della generazione precedente. Quando scrivi il codice, non ci pensi sempre. In effetti, molti programmatori scelgono di non considerare nemmeno come gli altri potrebbero voler avvicinarsi al codice 5 o 10 anni dopo che se ne sono andati. Una guida allo stile di codifica è un modo per un'azienda di concentrarsi su questi obiettivi di 5 e 10 anni, rendendo più facile per gli sviluppatori lavorare nello schema di cose più ampio.

D'altra parte, le guide di stile di codifica sono notoriamente imperfette, perché non è possibile sviluppare uno stile di codifica perfetto e scriverlo. In realtà inizi a incappare in casi d'angolo divertenti in cui le prove matematiche iniziano a fallire se cerchi di renderlo perfetto. Quindi sappiamo che le guide di stile di codifica sono imperfette. Potrebbero non concentrarsi perfettamente su ciò di cui abbiamo bisogno da 5 a 10 anni prima.

Se "imponessimo" uno stile di codifica, sacrificheremmo valore ora per valore in seguito. Questo sarebbe chiamato "investimento" se potessimo essere sicuri di ottenere un ritorno sui nostri sforzi, ma qualsiasi sviluppatore che abbia lavorato con una guida di stile di codifica scritta male può attestare che tali guadagni di "leggibilità" sono pagati a caro prezzo dagli sviluppatori che distraggono lontano dal loro codice. Nella mia esperienza, ci sono solo un numero molto piccolo di casi in cui gli stili di codifica forzata hanno un merito, in genere su software per clienti esclusivamente glaciali in cui il software può essere utilizzato per 30 o 40 anni!

Invece, trovo più efficace trattare una guida allo stile di codifica come un manifesto: "Questo è ciò in cui crediamo che il miglior stile di codifica sia per il nostro gruppo". È un mucchio di pensieri fluidi documentati a parole. La parola "credere" è importante: se le convinzioni cambiano, le guide di stile di codifica dovrebbero cambiare con esso.

È qui che entra in gioco la tua frase "forti obiezioni personali". In quello che definirei un mondo "perfetto", scrivi qualunque codice tu ritenga sia il migliore e vivi con le conseguenze. Spesso ci piace trascurare le conseguenze "soft" quando programmiamo, ma in questo caso sono importanti. Non ho alcun problema con te a scrivere nel tuo stile, se non ti dispiace non farti mai nulla di importante e duraturo da sviluppare.

Pensa a tutto il sistema come a un campo da golf. Lo stile di codifica spiana il facile percorso lungo il fairway. Se ti attieni allo standard di codifica, faremo in modo che la vita sia il più semplice possibile. Più ti addentri, usando i tuoi standard di codifica, più dovrai dimostrare il tuo valore alla squadra.

Se vengo lunedì mattina, per scoprire che hai passato tutto il weekend a risolvere un problema su cui ci siamo preoccupati per un anno, e lo hai fatto nel tuo standard di codifica "speciale", non ho intenzione di ti dico di aggiustarlo Sto per dirti di andare a fare una doccia. Se il tuo standard di codifica "speciale" è eccezionalmente "speciale", potrei persino suggerire a uno sviluppatore entry level di "recensire" il codice per diffondere la conoscenza di come funziona il tuo codice e dire in modo esplicito che se qualcosa sembra difficile da leggere, lui / lei dovrebbe riordinare. Questo fine settimana hai fornito alla società un valore sufficiente per cui non vale nemmeno la pena menzionare le gravi violazioni degli standard di codifica che hai commesso.

Ci sono, ovviamente, fuori limite in questa metafora del golf. Se ti chiedo di fare qualche compito di livello e file, magari aggiungendo nuovi campi a qualche modulo, e decidi di usare l'opportunità di rifattorizzare l'intero codice di compilazione per adattarlo al tuo stile particolare, usando un gruppo di caratteri loschi come definire macro e qualche tecnica di programmazione meta-terribile che hai appena imparato dallo scambio di pile, ti verrà chiesto di tornare indietro e sistemarlo. Hai scelto di agire, quelle sono le conseguenze.

( Disclaimer: ho completamente scritto questa implementazione di is_base_of per risolvere un compito umile, e ho guadagnato ogni piccola parte dell'inferno che ho ricevuto dagli sviluppatori senior, dico che ne è valsa la pena. Ricevo ancora una miriade di risate ogni volta che guardo come quel modello si incunea come 7 parti non correlate della specifica C ++ insieme per fare qualcosa di straordinario. Prendete questo, voi sviluppatori senior! Ecco cosa si ottiene per proibire boost su questo particolare progetto! )

Penso che la musica dell'umore qui sia che se la saggezza accettata è che gli standard di codifica sono errati o incompleti, allora è il minore dei due mali a premere se gli sviluppatori sono in generale d'accordo piuttosto che affrontare l'arduo processo di ottenere il documento modificato e riesaminato.

Va anche notato che le norme di applicazione standard del codice del passato non sono in genere il modo in cui le cose sono fatte ora.

In passato, ti sei limitato a tenere il tomo alla fine della scrivania degli sviluppatori e cita il capitolo e il verso perché il suo codice è in violazione della sezione 34.5.5767.

Ora disponiamo di strumenti per l'analisi del codice statico e la documentazione automatica che eliminano gran parte della complessità degli standard di codice.

In caso contrario, puoi comunque restituirlo allo sviluppatore, rilanciarlo in una revisione del codice o semplicemente modificarlo da solo se sei così inclinato.

La tua domanda è incentrata sulla riconciliazione delle due citazioni. Penso che ciò che treecoder ha scritto risponde alla tua domanda in generale. Rappresenta il tuo principio guida nella stesura delle linee guida di stile.

Più specificamente, dato che sei responsabile per l'impostazione delle linee guida per lo stile di codifica (questa è la mia ipotesi dal momento che sei lo scrittore di documenti), puoi decidere cosa è facoltativo o meno, e in che misura permetterti flessibilità nel personale stile della tua squadra. Riceverai feedback se necessario. Ma una volta che le linee guida sono a posto, resta con loro.

Quindi puoi conciliare le due contraddizioni apparenti come questa:

Pensa alla prima citazione che ti è stata rivolta come decisore di stile, prima che il documento delle linee guida sia completo. Se un certo standard di stile non funziona per la tua squadra, allora conta come una "strong obiezione personale" e le tue linee guida lo rifletteranno.

Pensa alla seconda citazione indirizzata alla tua squadra, dopo che il documento è stato completato. Dopo aver impostato le linee guida per il team e il documento è stato scritto, è importante che tutti gli sviluppatori del tuo team rispettino le linee guida sullo stile.

Non importa ciò che le persone in stile di codifica hanno, purché abbiano uno stile di codifica. Se una società insiste su uno stile di codifica, calpesta pesantemente il 49% circa dei suoi sviluppatori.

Il problema è che un gran numero di sviluppatori non si preoccupa molto di adattare il loro stile di codifica ad uno standard prevalente in un'azienda, ma gli importa molto di chi è meglio (o se ne preoccupa di più) dell'azienda politica.

Ciò significa che la creazione di uno standard di stile di codifica può essere un'enorme perdita di tempo, una fonte di discussioni senza fine, la causa di un risentimento infinito e, nel complesso, un'enorme perdita di tempo ed energia.

Best sembra utilizzare il formattatore di codice automatico che è una funzionalità integrata di quasi tutti gli IDE di discesa e dovrebbe esistere per quasi tutti i linguaggi di programmazione più o meno diffusi. Questo elimina tranquillamente un sacco di lavoro non necessario e molto attrito durante le revisioni del codice.

È del tutto ragionevole richiedere a tutti gli sviluppatori di sviluppare l'abitudine di applicare il formattatore alla sezione appena creata del codice.

La cosa peggiore che puoi fare è richiedere uno stile di codifica personalizzato che il formattatore di codice esistente non supporta.

In casi relativamente rari alcune sezioni possono essere formattate in modo diverso, se il formattatore lo fa veramente male, ma di solito è meglio regolare il formattatore affinché tutti formino meglio.

Potrebbero essere alcune regole utili che il formattatore non può supportare (come nominare le variabili, ad esempio) ma se rimangono solo queste sono relativamente facili da seguire.

Soluzione reale (non solo filosofia)

Consenti ai commenti del codice di ignorare il linting e compila gli elenchi di tali commenti se lo desideri (come succede spesso con i commenti di todo)

Offri ai tuoi sviluppatori la possibilità di lavorare al di fuori della convenzione in modo esplicito e con ragionevolezza e, durante le revisioni del codice da parte degli umani, può essere esaminato secondo necessità.