Imporre lo stesso formato di codice per tutti gli sviluppatori è una buona idea?

Attualmente lavoro in un posto in cui viene applicato un formato di codice standard e il codice viene formattato automaticamente quando si salva il file, proprio come si sta per fare. Come nuovo membro della compagnia ho scoperto che le comuni regole di formattazione mi davano una sensazione calda e confusa che "questi ragazzi sanno quello che stanno facendo", quindi non potrei essere più felice. ;) Come nota a margine correlata, con le regole di formattazione comuni applichiamo anche alcune impostazioni di avviso del compilatore piuttosto severe in Eclipse, con la maggior parte impostate su Errore, molte impostate su Avviso e quasi nessuna impostata su Ignora.

Direi che ci sono due ragioni principali per applicare un singolo formato di codice in un progetto. Prima ha a che fare con il controllo della versione: con tutti che formattano il codice in modo identico, tutte le modifiche nei file sono garantite per essere significative. Non più semplicemente aggiungendo o rimuovendo uno spazio qui o là, e tanto meno riformattando un intero file come un "effetto collaterale" di modificare effettivamente solo una o due righe.

La seconda ragione è che in pratica elimina gli ego dei programmatori dall'equazione. Con tutti che formattano il loro codice allo stesso modo, non è più facile capire chi ha scritto cosa. Il codice diventa più anonimo e di proprietà comune, quindi nessuno deve sentirsi a disagio nel cambiare il codice di "qualcun altro".

Quelle sono le ragioni principali, ce ne sono anche altre. Trovo confortante che non debba preoccuparmi di pensare alla formattazione del codice, poiché Eclipse lo farà automaticamente quando salverò. È privo di preoccupazioni, come scrivere documenti con LaTeX: è formattato in seguito e non devi preoccuparti di ciò mentre scrivi. Ho anche lavorato a progetti in cui ognuno ha i propri stili. Poi devi pensare a questioni stupide e prive di significato come se fosse giusto modificare il codice di qualcun altro nel tuo stile, o se invece dovresti provare a imitare il loro stile.

L'unico argomento contro le comuni impostazioni di formattazione del codice che posso pensare per il tuo caso è che apparentemente è un progetto già in corso, quindi causerà molte modifiche inutili in tutti i file, rovinando le cronologie dei file reali. Lo scenario migliore è se puoi iniziare ad applicare le impostazioni fin dall'inizio di un progetto.

Ogni sviluppatore di software professionale preferirà adottare uno (buono) standard piuttosto che entrare in guerre evangeliche con stile, proprio per le ragioni che lei ha delineato.

Molti sviluppatori di software conducono guerre evangeliche ......

A seconda della tua posizione all'interno della squadra e delle dinamiche del team, potresti decidere che vincere la guerra non è possibile. In questo caso, potrebbe essere meglio non iniziare ...

Sì, è bello avere uno stile di codice per tutti gli sviluppatori.

Disegna i formati di stile del codice e importalo a tutti gli sviluppatori di eclissi.

Questo ti aiuterà quando saremo merging di codice nel sistema di controllo della versione.

Che cosa stai cercando di ottenere, come ritenere anale lo farai rispettare (e nel livello di dettaglio le tue "regole" saranno definite), hai intenzione di provare ad applicarlo sul codice scritto in lingue diverse, hai intenzione di provare ad applicarlo retroattivamente sul codice esistente?

1. un comune aspetto del codice può effettivamente aiutare a rendere il codice più leggibile, ma può anche peggiorare le cose se è l'aspetto e il tatto errati. la notazione _hUngarian_lpfstr è un primo esempio:)
2. Ho visto "standard di codice" che impongono il numero di spazi di spazi bianchi tra i blocchi di commenti, l'ordine alfabetico dei nomi dei metodi e altre sciocchezze. Non farlo.
3. Diverse lingue hanno standard diversi a cui sono abituate le persone con esperienza nel loro utilizzo. Alcuni addirittura impongono questi standard (pensate che Python, Cobol, Visual Studio impongono automaticamente le convenzioni di rinforzo in stile C ++ mentre Java usa lo stile C per convenzione, ecc. Ecc.).
4. non cambiare mai il codice esistente per il gusto di cambiarlo, stai solo introducendo nuovi problemi in questo modo. E questo significa sezioni di codice e interi file sorgente. Quindi non andare in giro a riformattare il codice esistente quando qualcuno cambia una singola riga in un file di 1000 righe.
5. i programmatori esperti possono essere molto più produttivi se non devono pensare a metà del tempo se ciò che stanno scrivendo "guarderà bene" al sistema di approvazione automatica o al revisore. Avranno anche l'abitudine di scrivere codice pulito semplicemente perché è quello che funziona, anche se ci sono piccole differenze tra i loro stili naturali.

Quindi, anche se ci sono buone ragioni per imporre uno stile e uno standard specifici, ci sono buone ragioni per non farlo (troppo) rigorosamente.

Sì, la coerenza è una buona idea, per motivi altri hanno softwareengineering.stackexchange.com/a/189276/46461">mentioned.

• Oracle ha pubblicato un insieme di convenzioni per Java, che sono lo standard di fatto.
  • L'utilizzo di questi dovrebbe aiutarti a evitare argomenti su quale stile seguire.
  • Molte librerie pubbliche e progetti open source tendono a utilizzare queste convenzioni, quindi quando hai bisogno di guardare quelli che la formattazione dovrebbe avere familiarità.
  • Il formattatore di Eclipse ha regole integrate per soddisfare queste convenzioni, che dovrebbero anche aiutare.
• Potresti prendere in considerazione la possibilità di creare un hook nella configurazione del controllo del codice sorgente in modo che il codice venga formattato automaticamente prima di entrare nel ramo principale.
  • Puoi evitare battaglie con programmatori particolarmente testardi che si rifiutano di seguire lo standard. Possono persino utilizzare la propria formattazione mentre funzionano, che verrà standardizzata più tardi!
  • Se finisci per utilizzare le impostazioni di formattazione personalizzate (ad esempio, molte persone ignorano la convenzione "max 80 caratteri per riga") devi solo apportare modifiche in un unico posto.

Ero in un team che utilizzava il plug-in Checkstyle . Piuttosto che utilizzare le funzionalità out-of-the-box, abbiamo formato un piccolo comitato di sviluppatori interessati. Abbiamo discusso su ciò che sembrava mancante, ciò che sembrava eccessivo e martellava le cose. Tutti abbiamo imparato qualcosa nel processo e abbiamo rafforzato i muscoli dello sviluppatore.

(Esempi delle nostre decisioni: 72 caratteri di larghezza è troppo piccolo, ma 120 è stato migliore, è meglio usare _ALLCAPS per le finali statiche, applicare una singola uscita da una funzione è una buona idea.)

Quando abbiamo avuto recensioni di codice, una delle prime domande è stata: "Lo hai eseguito tramite Checkstyle?" Rispettare gli standard di codifica era in gran parte automatizzato, e distoglieva l'attenzione dal fatto che il recensore fosse pignolo. È stato straordinariamente facile che Checkstyle evidenzi una firma del metodo, clic con il tasto destro e modifica una variabile in finale. Potrebbe anche correggere le rientranze e le parentesi graffe in modo che il codice di tutti avesse un aspetto e un aspetto simile. Manca un Javadoc per una funzione pubblica? Checkstyle contrassegnerà la funzione.

(La rimozione dell'odore del codice è più importante della formattazione coerente. Questo è un vantaggio degli strumenti automatici.)

Metteremo strumenti automatici come Checkstyle in meno di imponendo lo stesso formato e altro su incoraggiando un aspetto simile. E quando stai radunando i gatti, uno strumento automatico può aiutarti ad affinare le capacità e ridurre l'odore del codice senza lividi di ego fragili.

Se hai intenzione di attenersi allo stesso IDE e incorporare alcuni strumenti di formattazione, è una buona idea perché non stai richiedendo troppo sforzo. Mantieni le regole semplici con attenzione alla leggibilità e non ritenzione anale . Quello dovrebbe essere il metro.

Anche se una palla di fango formata in modo coerente è meglio di una semplice palla di fango, il tuo tempo sarebbe meglio speso pulendolo invece di diventare troppo schizzinoso su dove vanno le parentesi. Non trasformarti nel manager con la punta di un pugno che si sente come se stessero facendo il loro lavoro contando gli spazi di rientro durante una revisione del codice e assicurandosi che nuove copertine sono nei rapporti TPS .

Le preferenze personali sono proprio quelle e raramente migliorano la produzione: link

Se lo fa, superalo e fai qualcosa.

Consiglio vivamente che gli umani applichino la formattazione del codice e che le infrazioni minori vengano gentilmente ignorate o modificate. I motivi di ciò sono, in breve,

1. La macchina si sbaglia nel momento peggiore, e solitamente quando si utilizza una nuova lingua. Come gestirà chiusure in Java, ecc? Jalopy ha problemi con le enumerazioni con le funzioni membro.
2. Penso che sia un onere molto ragionevole mettere il programmatore in grado di produrre codice per la società che assomiglia al codice dell'azienda. Ho trovato utile dire che questo è come il codice è formattato "qui", non come tutto il codice dovrebbe essere formattato ovunque. La loro precedente azienda potrebbe aver scelto un percorso diverso, e questo è OK. Non diversamente dal linguaggio volgare, ci sono degli idiomi specifici per la tua cultura del codice che vuoi far emergere.
3. L'applicazione della sintassi del codice viene eseguita al meglio con le revisioni del codice:
   1. Se la formattazione è importante, attira la tua organizzazione per eseguire revisioni del codice. Questo è di enorme beneficio.
   2. Se una regola di formattazione è interrotta, un essere umano può guardarlo e giudicare meglio di una macchina se l'intento viene trasmesso in modo più pulito. Questo è molto raro, ma succede occasionalmente.

Per quanto riguarda la "leggibilità = > produttività", la struttura del codice (come le classi e le funzioni a singola responsabilità) ti comprerà molto più velocemente della formattazione del codice. La formattazione del codice può essere di aiuto, ma le menti diverse analizzano le dichiarazioni in modo diverso - non tutti saranno "più produttivi". Vorrei raddoppiare la struttura del codice sulla formattazione, perché è qualcosa che ti porterà anche a fare revisioni del codice e far riflettere il team su come funziona il programma, non su come appare un singolo loop.

Non sono un grande fan di Domain Driven Design, ma è un modello recente che ha un'idea MOLTO ben definita su come il codice dovrebbe essere strutturato e le convenzioni di formattazione del codice fluiscono naturalmente da un programma strutturato Domain Driven Design. Ancora ... Non mi piace il DDD, ma è un ottimo esempio perché è così ben definito.

Suppongo che il tema di questa risposta sia Esegui revisioni del codice e che la formattazione fluisca dalla cultura e dal processo di revisione.

In generale, supponendo che assumiate sviluppatori ragionevoli, è una cattiva idea imporre un formato di codice universale. È comunque una buona idea adottare il codice linee guida .

Non ho mai visto una serie di regole di formattazione del codice che ottimizzano la leggibilità in tutti i casi. Allo stesso modo non ci sono regole grammaticali applicabili al 100% in inglese: i nostri cervelli non sono cablati in questo modo. Quindi, usa le linee guida, ma concedi agli sviluppatori la libertà di ignorarle come meglio credono.

Detto questo, una regola più dura di "seguire la convenzione di codice che già esiste nel file / progetto" è buona.

Ma tieni presente che la formattazione contribuisce molto meno alla leggibilità rispetto alla semplice organizzazione logica del codice. Ho visto molti codici illeggibili per gli spaghetti con una formattazione perfetta!

Non penso che ci sia una risposta semplice a questo. Non è una domanda si o no. Mentre credo che lo stile e le convenzioni sui nomi siano importanti in una certa misura, è anche abbastanza facile perdere troppo tempo a pensarci. È meglio rispondere con l'esempio.

In un particolare progetto in cui mi trovavo, non c'erano affatto convenzioni. Ogni sviluppatore ha fatto le cose a modo suo. A causa della relativa inesperienza di questa squadra, passare da una classe all'altra era davvero sconvolgente. Lo stile era meno di un problema rispetto al problema delle convenzioni di denominazione. Uno sviluppatore farebbe riferimento a elementi dell'interfaccia utente con notazione ungherese terribile (una pratica stupida nell'era dei moderni IDE), uno chiamerebbe i membri privati in un modo, un altro li chiamerebbe in modo diverso. Non hai mai saputo cosa stavi guardando.

All'estremo opposto, un team ha utilizzato StyleCop (questo era un progetto .Net) come parte del processo di compilazione. Quel che è peggio, è che hanno anche usato la maggior parte delle regole predefinite. Quindi dovresti fare qualcosa di totalmente normale in termini di spaziatura delle linee o posizionamento delle parentesi graffe, e la costruzione potrebbe vomitare a causa di esso. Così tanto tempo è stato sprecato solo aggiungendo spazi e linee alle cose, e tutti, compresi i tizi che hanno insistito nell'uso di StyleCop, hanno finito per farlo quasi ogni commit. È stato un enorme spreco di tempo e denaro.

Quindi il punto che sto facendo qui è che essere inflessibili non è la risposta, ma nemmeno essere nel selvaggio West. La vera risposta è trovare il posto che ha più senso, che a mio avviso è di non avere strumenti automatizzati per controllare le cose, ma non di organizzare convention al vento, neanche.

Il mio principale argomento contro lo stile di codifica comune è che un programmatore esperto viene utilizzato per leggere il proprio stile. Puoi allenare la mano per scrivere uno stile specifico ma è quasi impossibile addestrare l'occhio a capire uno stile che odi. Un programmatore scrive una parte di codice una volta e poi la legge più e più volte durante lo sviluppo e il debug. Se ogni volta che legge il suo codice si sforza di capirlo perché è stato costretto a scriverlo in uno stile BAD, sarà molto infelice e meno produttivo. Questo deriva dalla mia esperienza precedente.

Non ho molta familiarità con Eclipse, ma il formato automatico su save sembra un'idea orribile. Uno sviluppatore deve avere il controllo completo sul suo codice indipendentemente dal fatto che lo stile di codifica sia imposto o meno. L'operazione 'salva' non deve cambiare un singolo carattere senza il consenso esplicito dell'utente.

Se la tua azienda vende codice sorgente, lo stile di codifica è più importante, ma se vendi codice compilato, è molto meno rilevante.

Sperando che lo stile di codifica possa rendere il codificatore originale meno distinguibile e prevenire le guerre dell'ego è una cazzata nel migliore dei casi e semplicemente stupido nel peggiore dei casi. I grandi programmatori produrranno sempre codice elegante a prescindere dallo stile.

Inoltre, sono strongmente pro fornendo a tutti gli sviluppatori la proprietà di specifiche unità di codice e impedendo a chiunque di toccare liberamente ogni pezzo di codice. Sviluppare intere unità nel codice ed esserne responsabili consente allo sviluppatore di crescere con orgoglio nel suo lavoro e impedirgli di sviluppare codice scadente sapendo che i bug torneranno a dargli la caccia.

Infine, chiunque abbia uno stile di codifica pro presume sempre che il proprio stile di codifica sarà selezionato e tutti gli altri seguiranno. Immagina che lo stile di codifica che meno ti piace da tutti i tuoi co-sviluppatori sia selezionato come standard. Sei ancora favorevole all'imposizione di uno stile di codifica?

I buoni sviluppatori sono persone creative, danno loro una licenza artistica. "Keep it simple" dovrebbe essere il mantra dei programmatori. Ho due regole:

Regola 1: dare variabili / cursori / oggetti / procedure / qualunque NOMI SENSIBILI. Nomi univoci che portano significato e comprensione al tuo codice.

Regola 2: utilizza il rientro per mostrare la struttura del tuo codice.

Questo è tutto.

Per me, il vantaggio principale di un formato comune applicato automaticamente è che aiuta il nostro rilevamento delle modifiche & recensioni di codice. git (e la maggior parte degli altri strumenti di controllo del codice sorgente) possono mostrare le differenze tra le versioni precedenti dei file. Applicando uno stile comune, minimizzando le differenze di programmazione del programmatore.

Un formato per dominarli tutti ... è davvero ottimale?

È come guidare la macchina di qualcun altro ...

Sicuramente puoi salire e guidare qualsiasi auto, ma sarai più sicuro, più a tuo agio e meno probabilità di schiantarti se prendi il tempo di regolare sedile, volante e specchi su TUO preferenza.

Con il codice, la formattazione influisce sul tuo comfort nella lettura e comprensione del codice. Se è troppo lontano da ciò a cui sei abituato, richiederà un maggiore sforzo mentale. È necessario infliggerlo sugli sviluppatori?

+1 a tutti i vantaggi menzionati finora, ma ...

L'applicazione automatica viene fornita con costi che devono essere considerati:

-1 al fatto che i programmi di formattazione del codice non comprendono l'estetica della formattazione del codice. Quante volte hai avuto un formattatore di codice distruggere un blocco di commenti che era ben allineato in una tabella? Quante volte hai allineato di proposito un'espressione complessa in un certo modo per aumentare la leggibilità, solo per avere la formattazione automatica che la maneggia in qualcosa che "segue le regole", ma è meno leggibile?

A volte ci sono soluzioni alternative a queste cose, ma gli sviluppatori hanno a che fare con cose più importanti di come mantenere il formattatore automatico dal mangling del codice.

Hai regole di formattazione, ma consenti ad alcune libertà di applicare il buon senso.

Le guide di stile consentono inoltre di semplificare l'analisi programmatica del codice per vari scopi analitici.

Google ha pubblicato un documento su questo argomento denominato " Alla ricerca di un debito di costruzione: Esperienze Gestione del debito tecnico su Google ".

Le lingue non sono codici. Noi umani abbiamo più di 6000 lingue, quindi le traduciamo. Quindi se vuoi che i tuoi "codici" comunichino devi fare le tue regolazioni. Vedi noi utenti dobbiamo modificare i nostri formati di dati in modo da non perdere i nostri dati.

Direi che non lo è. Una struttura / formato di codice comune tra una squadra è sicuramente una buona cosa, ma la sua applicazione automatica non lo è. Questo dovrebbe essere fatto dagli umani, non dal computer.

I miei maggiori problemi con il concetto sono

1. Se sto scrivendo il codice in un formato e viene automaticamente riformattato, qual è l'incentivo per imparare effettivamente quel formato?
2. Seguendo il punto precedente, se non si impara il formato, l'intero punto dell'autoformattazione (per rendere il codice più facilmente leggibile e modificato) viene completamente perso. Devi ancora dedicare del tempo a capire la formattazione mentre stai leggendo il codice perché non hai imparato quel formato
3. Penso che sarebbe un'esperienza spiacevole come un dev di scrivere una lezione un giorno, chiuderla e tornare il giorno dopo per vederla completamente diversa. Ciò significa che non solo gli altri devono imparare il tuo codice, tu devi imparare il tuo codice.
4. Potrebbe anche incoraggiare la codifica pigra. Invece di spingere il dev per imparare il formato, possono scrivere in qualsiasi formato sotto il sole e appariranno automaticamente come tutti gli altri vogliono. Questo torna al n. 2 in cui non si impara lo stile e non si riesce ancora a leggerlo correttamente.

Ora, potrei essere propenso a dire che l'esecuzione di un auto-formato su un progetto che è tutto racchiuso sarebbe una buona idea. In questo modo, all'avvio di fix / add feature verranno avviati tutti gli sviluppatori sullo stesso piano del progetto. Durante lo sviluppo attivo, tuttavia, penso che sia una scelta molto scarsa.

Sostanzialmente: attribuire la responsabilità al dipendente di apprendere lo stile dell'azienda, non forzare il proprio codice ad essere qualcosa che non è.