Quanto sono importanti le linee guida per la formattazione del codice? [chiuso]

Gli standard di codifica sono comuni in qualsiasi organizzazione di sviluppo software, ma quanto sono importanti da seguire? Riesco a capire la necessità di una certa coerenza, ma quando si tratta di cose semplici come la posizione delle parentesi graffe, la lunghezza della linea, ecc., Non sono sicuro che standard eccessivamente rigidi contribuiscano molto allo sviluppo del software.

Non è più importante che il tuo codice sia leggibile, non che sia conforme a uno standard predefinito? Sembra che siano più come ... linee guida comunque.

Chiedere a tutti al 100% di aderire alle stesse linee guida standard per la formattazione del codice è come chiedere a tutti di collaborare separatamente alla scrittura di un documento di 100 pagine con lo stesso stile di scrittura.

Spero che tutti scriveranno il documento in inglese (o nella stessa lingua), ma appariranno stili diversi. Alcuni lo scriveranno bene, altri no. Alcuni useranno le contrazioni, altri scriveranno completamente le parole (esempio: è vero che è). Eccetera.

Penso che tu abbia toccato i punti più importanti:

1. È una linea guida
2. leggibilità

Se si desidera che il codice aderisca alla stessa formattazione, ad esempio un documento con lo stesso stile di scrittura, sarà necessario modificarlo e modificarlo. Il codice dovrà essere ripulito, rivisto, ricodificato, ecc.

Non sono mai stato in un negozio in cui ero completamente soddisfatto dello stile o della formattazione di un altro sviluppatore (al minimo perché non è esattamente come il mio). Ma sarò contento se posso leggerlo / comprenderlo e se è coerente. Tutto il resto è lo zucchero sullo zucchero sintattico.

Quindi, per rispondere alla tua domanda: un po 'importante, ma non è certamente la fine del mondo se non lo fanno.

Per gli standard di formattazione, seguo quello che fanno tutti gli altri. Se usano PascalCase per tutto, allora uso PascalCase. Se usano _camelCase, allora uso _camelCase. Perché? Perché limita la quantità di riformattazione che faccio e limita ciò che gli altri devono fare per renderlo "bello". Gli standard di formattazione sono di solito lì per rendere le cose facili per tutti.

Nel mio attuale lavoro, uno dei miei primi compiti era quello di elaborare uno standard di codifica per il nostro gruppo di sviluppo.

Il mio primo sforzo fu lungo una sessantina di pagine (incorporava gran parte delle Linee guida del Framework di Microsoft). Mi è stato chiesto di ridimensionarlo e il mio prossimo sforzo è stato lungo dieci pagine, utilizzando idee provenienti da una varietà di buone fonti. Mi è stato chiesto di ridimensionarlo di nuovo, e alla fine l'ho ridotto a tre o quattro pagine, credo.

Non è mai stato adottato.

Perché? Perché lavoro con molte persone davvero intelligenti, che seguono istintivamente uno standard di codifica ragionevole.

Da parte mia, seguo le linee guida generalmente accettate da Microsoft ed emulo gli stili comunemente utilizzati da altri (Javascript e jQuery sono formattati in modo diverso da C #, anche se entrambi sono linguaggi di parentesi graffe). Di tanto in tanto rompo le regole, quando ciò renderà il codice più leggibile.

Se usi un IDE che fa le basi di questo per te (ad esempio Visual Studio), lascia che l'IDE faccia la sua cosa e qualunque cosa sembri ancora difficile da guardare, modifica fintanto che lasci ancora che l'IDE faccia la sua cosa o la prossima persona che si auto-formatta lo ucciderà comunque.

Ciò che è più leggibile per una persona non lo sarà per tutte le persone.

Se non stai usando questo tipo di IDE, prendine uno. Anche pensare a questo per più di 10 minuti è uno spreco di risorse IMHO.

Penso che ci sia un vantaggio non menzionato nell'aiutare a comprendere rapidamente il codice. Più simile è la formattazione del codice in un progetto e tutti gli sviluppatori, più facile (e inconsciamente) sarai in grado di lavorare con il codice.

Ho avuto sviluppatori junior che sono venuti da me dopo aver provato a gestire anche semplici bug per un lungo periodo di tempo. Dopo aver impiegato alcuni minuti per applicare il nostro formato di codice con loro, sono stati rapidamente in grado di vedere il bug che avevano perso prima.

Mentre la leggibilità è sicuramente importante. Se i tuoi standard di formato del codice sono ben studiati e sono usati correttamente, potresti scoprire che puoi andare oltre la semplice lettura del codice e la possibilità di comprenderlo ancora più rapidamente.

Una serie di linee guida che utilizzo quando sviluppo o aggiorno i nostri formati di codifica sono i Principi di raggruppamento Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Come risultato diretto / esempio, la nostra formattazione del codice richiede che qualsiasi codice di blocco (if, switch, ecc.) Abbia la parentesi aperta sulla riga successiva, in modo che si allinei con la parentesi graffa di chiusura:

if(true)
{
}

Con il ragionamento secondo il Principio di simmetria, la tua mente vedrà le parentesi graffe aperte e chiuse e più rapidamente sarà in grado di percepire il blocco di codice in modo naturale.

Indipendentemente dalla lingua o dallo strumento che usi, crea qualcosa. Configura il tuo IDE e controlla nel file di configurazione.

Quando qualcuno verifica il progetto, utilizzerà gli stessi stili di formattazione. Non importa quale sia lo stile, solo che è coerente. Ho le mie preferenze per quanto riguarda gli spazi v. Tab, e quale linea continuano le parentesi graffe. Ma più delle mie preferenze, mi interessa solo che un determinato file di codice sorgente sia d'accordo con se stesso. Lo rende molto più leggibile di quanto sia un miscuglio risultante da una guerra di formato.

La cosa peggiore che ho riscontrato finora è l'utilizzo di standard di codifica. E ti è vietato rendere alcuni blocchi di codice più leggibili perché interrompe gli strumenti diff ... Perché stiamo usando le patch per applicare le modifiche (modifica / richiesta correzione bug -> correzione / modifica -> patch -> patch applicata da una persona "fidata" -> commit) puoi ottenere un codice sorgente piuttosto divertente (dal punto di vista della leggibilità). Almeno non abbiamo nessuno che usa due lettere variabili (-.

[rant] La cosa più divertente è che tutti concordano sul fatto che dobbiamo cambiarlo. Ci sono stati anche un paio di tentativi di riformattazione (automatizzati in commit), ma poiché manca un'unica piccola opzione di formattazione, la cosa è appena finita. Vista ... [/ rant]

Le linee guida aiutano a migliorare la qualità del codice:

• dal punto di vista dello scrittore: molte regole mirano a ridurre l'introduzione di bug. Ad esempio, una regola che afferma che if()o i for(;;)costrutti devono essere seguiti da un blocco e non da una singola istruzione, rende esplicita l'intenzione del programmatore iniziale e aiuta i programmatori successivi a mantenerlo.

• dal punto di vista del lettore: il codice che segue le linee guida concordate viene rivisto in modo più efficiente rispetto al codice con vari stili. Il revisore conosce meglio con meno sforzo dove cercare possibili bug.

Non esiste uno standard universale per ciò che una squadra dovrebbe o non dovrebbe fare. Alcuni team devono seguire rigide linee guida, altri no.

Il punto è che dovresti lavorare insieme come una squadra e decidere cosa è meglio per la tua squadra . Il codice dovrebbe essere facile da leggere, perché viene letto ordini di grandezza più volte di quanto sia scritto. Se il tuo team ha bisogno di assistenza per creare codice leggibile, segui uno standard di codifica. Se non lo fai, non farlo.

Detto questo, penso che la maggior parte dei team trarrebbe beneficio dal concordare un modo standard per nominare variabili, funzioni e classi, posizionare le parentesi graffe e così via. Se la squadra non può essere d'accordo su qualcosa di così semplice, come può aspettarsi di riunirsi e prendere decisioni davvero importanti? Inoltre, la tua squadra non sarà formata dalle stesse persone per sempre: le persone se ne vanno, vengono assunte nuove persone. Più è facile per le nuove persone individuare il codice base, più rapidamente possono contribuire al team senza ridurre la qualità del codice.