Lo stile di programmazione nelle organizzazioni è una cosa facoltativa?

Questo documento di stile di programmazione ha una regola generale, che dice:

Le regole possono essere violate se vi sono forti obiezioni personali nei loro confronti.

Questo si scontra con il modo in cui sto pensando, e ci sono molti articoli che affermano che lo stile di programmazione è in realtà importante. Ad esempio questo dice:

Un documento sugli standard di codifica indica agli sviluppatori come devono scrivere il loro codice. Invece di codificare ogni sviluppatore nel proprio stile preferito, scriveranno tutto il codice secondo gli standard delineati nel documento. Questo assicura che un grande progetto sia codificato in uno stile coerente - le parti non sono scritte in modo diverso da programmatori diversi. Questa soluzione non solo semplifica la comprensione del codice, ma assicura anche che qualsiasi sviluppatore che lo guardi sappia cosa aspettarsi nell'intera applicazione.

Quindi, sto fraintendendo qualcosa da questo documento e dalla citazione in cima a questa domanda? Le persone possono davvero ignorare lo stile di programmazione?

Forse non ero abbastanza chiaro, quindi con questa modifica, chiarirò un po '.

Sto scrivendo il documento sullo stile di codifica per il nostro team e voglio verificare lo stile usando alcuni analizzatori statici. Se fallisce, Jenkins invierà e-mail. E voglio fallire la revisione del codice, se lo stile non corrisponde. Ciò si scontra chiaramente con la prima citazione.

Ma poi, se la citazione è giusta, a che serve il documento di stile di codifica, se qualcuno può fare quello che vuole?

Per quanto posso dire, l'affermazione che ti ha confuso è un compromesso pragmatico fatto affinché le linee guida servano il più vasto pubblico possibile. A seconda del contesto specifico (più su quello che segue) potresti avere un'opzione per adattarlo 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 alla leggera, soprattutto se provengono da sviluppatori esperti.

Queste obiezioni possono essere sbagliate, intendiamoci, ma (e questo è molto, GRANDE MA) possono anche indicare che una determinata regola è sbagliata - in generale o nel contesto del progetto specifico (un esempio di disadattamento della regola è un requisito da fornire registrazione dettagliata nel codice critico per le prestazioni).

Penso che qualsiasi guida di stile sensata dovrebbe tenere conto di 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 in modo molto meno ambiguo, ad esempio in questo modo:

Le regole dovrebbero essere seguite rigorosamente, a meno che non venga sollevata una sfida contro di loro - nel qual caso la regola contestata dovrebbe rimanere ignorata fino a quando non viene risolta - rifiutando la sfida o accettandola e adattando le regole per adattarle.

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

Vedete, quell'approccio sfida-e-ignora-fino a quando non è stato risolto potrebbe aprire un'ampia porta agli abusi se fosse presentato come guida per qualsiasi progetto. "Sì, sì, ti sentiamo, facciamolo come dice la guida. Prima di tutto, compila questo modulo di richiesta e ottieni le approvazioni di CEO / CFO / CTO; aspettati che ciò richieda una o due settimane. Successivamente, attendi fino a quando non aggiorneremo i nostri controlli del codice ; ciò potrebbe richiedere un'altra settimana o due. Nel frattempo, assicurati che il tuo codice critico per le prestazioni vomiti istruzioni di registrazione correttamente formattate su ogni spostamento del registro. "

Non riesco a leggere le menti degli autori della guida, ma sembra ragionevole supporre 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 assume alcuna applicazione - in questo modo, per quanto goffa, consente comunque di essere utilizzabile per una gamma arbitrariamente ampia di team e progetti. Probabilmente ci si aspetta che un'indennità così ampia lasci ai team più maturi ed efficienti l'opportunità di restringerla 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 potrebbe richiedere agli sviluppatori di sfidare una determinata regola, farla ignorare, risolto e averlo modificato o ripristinato a seconda della 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 prendere in considerazione un approccio di sfida / risoluzione formalizzato e facile da tracciare invece del caotico "violare se piangi abbastanza forte".

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

Questo è un presupposto pericoloso, davvero. Mi sono rotto il naso (due volte! In un singolo progetto! Dove ho avuto una vasta esperienza e ho immaginato di sapere tutto a riguardo, vai a capire) e ti consiglio vivamente di lasciarlo cadere. È più sicuro supporre che la guida di stile possa avere errori e sforzarsi di pensare a cosa fare nel caso in cui tali errori vengano scoperti.

Consentire alle persone di ignorare gli stili di codifica a causa delle preferenze personali è 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 il punto, che sta portando tutti i membri del team a fare le cose allo stesso modo per coerenza e leggibilità.

Concordo 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 in modo sleale una linea guida potrebbe impedire il modo migliore di scrivere un particolare codice . Gli sviluppatori dovrebbero essere in grado di ignorare le linee guida e dimostrare che ciò che hanno fatto è il modo migliore e più leggibile per realizzare qualcosa in questo caso.
• Lavorare con il codice legacy potrebbe richiedere flessibilità. Probabilmente non è un buon uso del tuo tempo per ridisegnare una grande base di codice esistente. Se riscrivi una sezione in modo significativo, puoi riformattarla nello stile preferito. Tuttavia, se fai solo una piccola modifica, potrebbe essere meglio usare lo stile esistente del codice.
• Nitpicking su ogni piccola violazione della guida di stile non è un buon uso del tempo. La revisione del codice è un buon momento per evidenziare qualsiasi codice che sia significativamente fuori linea con lo stile del team. Tuttavia, è probabile che catturare e correggere piccoli "errori" di stile diventi un lavoro impegnativo incentrato 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 rientro mal riposta, non importa di fallire qualcuno su questa base.

In conclusione: consentire flessibilità nell'aderire alle linee guida di stile, al fine di soddisfare al meglio le esigenze del proprio team, 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 adattamento) lo stile di codifica per soddisfare le esigenze dell'organizzazione dipende da quanto aiuta a rendere le cose comprensibili.

Ricorda, tutto, e sottolineo, TUTTO, dalla programmazione OO ai paradigmi funzionali, ai vari modelli di concorrenza, esiste per la sola ragione di aiutare le persone a gestire la complessità.

Ogni pazzo può scrivere codice comprensibile a un computer. I bravi programmatori scrivono codice che gli umani possono capire. - Martin Fowler, 2008

Lo stile di programmazione nelle organizzazioni è una cosa facoltativa?

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

Quindi la citazione che stai leggendo affronta il problema più grande che vedo per quanto riguarda lo "stile" di codifica e i veri "hacker" superstar - porti un nuovo ragazzo a bordo e scrive un codice che farà cadere gli zombi e fa urlare velocemente quei tuoi vecchi server. .. 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 al suo stile particolare richiederà tempo e denaro. E adesso?

La maggior parte dei super hacker che conosco provengono da ego 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 da poter lasciare che questo killer hacker continui a scrivere un codice veloce e sorprendente con un po 'di devianza di stile, ma assicurati che tutti lo capiscano fino a quando non raggiungono il suo hacker epico stato, devono seguire le regole (o addirittura aiutare a ripulire dopo di lui).

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

Quindi, sto fraintendendo qualcosa da questo documento e dalla citazione in cima a questa domanda? Le persone possono davvero ignorare lo stile di programmazione?

Dipende.

Il posto in cui mi trovo attualmente non ha una guida di stile e non è un grosso problema. Esistono alcune lievi variazioni tra i programmatori, ma non tanto da influire sulla leggibilità, sulla rilevabilità o sulla coerenza in alcun modo significativo. E abbiamo un gruppo abbastanza grande e una cultura abbastanza forte da far sì che qualsiasi nuovo membro del team si allinei (o altro).

Nelle aziende precedenti, stavamo crescendo rapidamente e avevamo alcune persone che non avevano familiarità con la lingua e i suoi modi di dire. In quella compagnia, l'afflusso di persone significava che non esisteva una cultura che imponesse una buona scrittura. E le persone che non conoscevano la lingua significavano che c'erano molte cose da adattare. Là i controllori di stile automatizzati erano il modo più efficiente di effettuare le regolazioni e una vera guida scritta era il modo migliore per addestrare le nuove persone nelle nostre aspettative.

Personalmente, non mi importa molto delle guide di stile, e ancora meno mi occupo di un'applicazione automatizzata dello stile. Se la persona non riesce nemmeno a cogliere gli idiomi di base, perché li stai impiegando come programmatore? E se sono un giocatore di squadra così cattivo che scriveranno continuamente codice con cui gli altri trovano difficile lavorare, perché li stai impiegando?

Questo più di uno stratagemma psicologico invece di un'interpretazione letterale del modo migliore di gestire gli stili di codifica. Rende il team / azienda / manager / leader meno autoritario. Mi concentrerei maggiormente sulle eccezioni situazionali anziché personali. Indipendentemente dal documento di codifica, l'obiettivo è rendere le cose facili da leggere. Il codice di confusione dovrebbe essere affrontato e modificato se ritenuto necessario. Ci sono molti strumenti per prendersi cura delle piccole cose noiose, quindi usale.

Ci sono eccezioni ad ogni regola. Dai alle persone "un po '" spazio di manovra. Meno tutti sono coinvolti nell'accettare le regole dello stile di codifica (Welcome new guy.), Più sono inclini a voler reagire. 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 sulla codifica invece di combattere su ogni piccolo dettaglio e interpretazione.

Sì, arriverà un momento in cui il documento in stile codice non ha senso usare e agli sviluppatori professionisti e adulti dovrebbe essere permesso di conoscere la differenza.

Sulla base delle tue modifiche, il tuo obiettivo per l'obiettivo giusto.

Ci sono molti vantaggi nell'usare una guida di stile, ma i due più importanti secondo me sono la leggibilità del codice tra i membri del team e la mancanza di commit "sciocchi" (come solo spazi bianchi, o linee extra e simili).

Per raggiungere il tuo obiettivo, la guida di stile che hai scelto (o creato) dovrebbe essere semplice e facile da aderire. Cerca di concentrarti davvero su ciò di cui hai bisogno. A nessuno piace tornare indietro e riscrivere un enorme campione di codice solo per rendere felice una linter. Ma potrebbero esserci ancora dei benefici.

Assicurati che i membri del tuo team approvino la guida di stile. Li vincerai, assicurati che siano d'accordo o sarà una lotta eterna.

Assicurati che le violazioni di stile siano un "avvertimento" e non un "fallimento", lascia che un essere umano decida se la violazione incontra un fallimento. Il motivo è semplice. Credo in un flusso di lavoro semplice. Se da qualche parte nella fase di "test" si verifica un "fallimento", non è possibile passare alla produzione. Uso come sicurezza. Anche le hot fix devono passare attraverso una fase di test (anche se più breve). Puoi davvero dire che non porterai quella correzione di bug critici alla produzione perché qualcuno ha usato un "invece di un"? Che ne dici di usare un ciclo for anziché un ciascuno? Cosa succede se un ciclo for ha qualche miglioramento rispetto a ciascuno? sono decisioni che una macchina (linter) non può prendere, quindi assicurati di avere un essere umano, giudica l'avvertimento e non la macchina lancia un guasto.

Per quanto riguarda l'ignorare la guida di stile, dovrai giudicarla caso per caso. Assicurati che la "deviazione" abbia una vera ragione. Verranno. Il compito dei revisori è quello di assicurarsi che ci sia una buona ragione per la deviazione e non banale.

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 insistere se gli sviluppatori sono in accordo generale piuttosto che passare attraverso l'arduo processo di ottenere documento modificato e rivisto.

Va anche notato che le politiche di applicazione standard del codice di un tempo non sono in genere il modo in cui le cose vengono fatte ora.

Ai vecchi tempi, avresti semplicemente alzato tenendo il tomo alla fine della scrivania degli sviluppatori e citando il capitolo e il verso perché il suo codice è in violazione della sezione 34.5.5767.

Ora disponiamo di strumenti di analisi del codice statico e di auto-documentazione che eliminano gran parte della fatica degli standard del codice.

In mancanza di tutto ciò, puoi ancora restituirlo allo sviluppatore, sollevarlo in una revisione del codice o semplicemente cambiarlo tu stesso se sei così incline.

La tua domanda è incentrata sulla riconciliazione delle due virgolette. Penso che ciò che treecoder abbia scritto risponda alla tua domanda in generale. Rappresenta il tuo principio guida nella scrittura di linee guida di stile.

Più specificamente, dal momento che sei responsabile dell'impostazione delle linee guida sullo stile di codifica (questo è il mio presupposto poiché tu sei lo scrittore di documenti), puoi decidere cosa è facoltativo o meno e in che misura consentirai flessibilità nello stile personale del tuo squadra. Riceverai feedback dove necessario. Ma una volta che le linee guida sono state stabilite, attenersi a esse.

Quindi puoi conciliare le due apparenti contraddizioni in questo modo:

Pensa alla prima citazione indirizzata a te come al decisore di stile, prima che il documento delle linee guida sia completo. Se un determinato standard di stile non funziona per il tuo team, questo conta come una "forte obiezione personale" e le tue linee guida lo rifletteranno.

Pensa alla seconda citazione come indirizzata al tuo team, dopo che il documento è stato completato. Dopo aver impostato le linee guida per il team e aver scritto il documento, è importante che tutti gli sviluppatori del team aderiscano alle linee guida di stile.

Non importa troppo quale sia lo stile di codifica che le persone hanno, purché abbiano uno stile di codifica. Se un'azienda insiste su uno stile di codifica, calpesta pesantemente circa il 49% dei suoi sviluppatori.

Il problema è che un gran numero di sviluppatori non si preoccupa molto di adattare il loro stile di codifica ad alcuni standard prevalenti in un'azienda, ma si preoccupano molto di essere raccontati da coloro che sono più bravi (o semplicemente si preoccupano di più) della politica aziendale.

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

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

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 addestreremo i nuovi sviluppatori a 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ù semplice per gli sviluppatori lavorare nello schema più ampio delle cose.

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 imbatterti in divertenti casi angolari in cui le prove matematiche iniziano a fallire se provi a renderlo perfetto. Quindi sappiamo che le guide di stile di codifica sono imperfette. Potrebbero non concentrarsi perfettamente su ciò di cui abbiamo bisogno tra 5 e 10 anni.

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

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

È qui che arriva la tua citazione di "forti obiezioni personali". In quello che definirei un mondo "perfetto", scrivi qualunque codice ritieni migliore e vivi con le conseguenze. Spesso ci piace trascurare le conseguenze "leggere" durante la programmazione, ma in questo caso sono importanti. Non ho problemi a scrivere nel tuo stile, se non ti dispiace non darti mai qualcosa di importante e di lunga durata da sviluppare.

Pensa all'intero sistema come a un campo da golf. Lo stile di programmazione apre la strada facile lungo il fairway. Se ti mantieni allo standard di codifica, faremo in modo che la vita sia la più semplice possibile. Più esci dal grezzo, usando i tuoi standard di codifica, più dovrai dimostrare il tuo valore nel team.

Se vengo lunedì mattina, per scoprire che hai passato tutto il fine settimana a risolvere un problema che ci siamo preoccupati per un anno, e l'hai fatto nel tuo standard di codifica "speciale", non ti dirò di aggiustalo. Ti dirò di andare a farmi una doccia. Se il tuo standard di codifica "speciale" è eccezionalmente "speciale", potrei anche suggerire a uno sviluppatore entry level di "rivedere" il codice per diffondere la conoscenza di come funziona il tuo codice e menzionare con disinvoltura che se qualcosa sembra difficile da leggere, dovrebbe riordinalo. Nel fine settimana hai fornito abbastanza valore all'azienda che non vale nemmeno la pena menzionare le violazioni degli standard di codifica che hai commesso.

Ci sono, ovviamente, fuori limite in questa metafora del golf. Se ti chiedo di eseguire alcune attività di rango e file, magari aggiungendo nuovi campi in qualche modulo, e decidi di sfruttare l'opportunità di riformattare l'intero codice di compilazione del modulo in base al tuo stile particolare, usando un gruppo di caratteri ombreggiati come definire le macro e qualche terribile tecnica di meta-programmazione del modello che hai appena imparato dallo scambio di stack, ti ​​verrà chiesto di tornare indietro e risolverlo. Hai scelto di agire, queste sono le conseguenze.

( Dichiarazione di non responsabilità: ho completamente scritto questa implementazione di is_base_ofper risolvere un compito umile, e ho guadagnato tutto l'inferno che ho ottenuto per gli sviluppatori senior. Dico che ne è valsa la pena. Continuo ad avere una bolla di risate prodigiosa ogni volta che guarda come quel modello si incunea come 7 parti non correlate della specifica C ++ per fare qualcosa di straordinario. Prendi questo, sviluppatori senior! Ecco cosa ottieni per aver proibito boostquesto particolare progetto! )

Best sembra utilizzare il formattatore di codice automatizzato che è una funzionalità integrata di quasi tutti gli IDE di discendenza e dovrebbe esistere per quasi tutti i linguaggi di programmazione più o meno diffusi. Ciò elimina silenziosamente molto lavoro inutile e molti attriti durante le revisioni del codice.

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

Il peggio 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 formatter lo fa davvero terribilmente, ma di solito è meglio regolare il formatter affinché tutti possano formattare meglio.

Possono 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 sul codice di sovrascrivere la lanugine e, se lo desideri, compila gli elenchi di tali commenti (come spesso accade con i commenti dodo)

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