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

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

Speriamo che tutti scrivano il documento in inglese (o nella stessa lingua), ma diversi stili saranno evidenti. Alcuni lo scriveranno bene, altri no. Alcuni useranno le contrazioni, alcuni scriveranno le parole completamente (esempio: è vero che è). Ecc.

Penso che tu abbia toccato i punti più importanti:

1. È una linea guida
2. La leggibilità

Se vuoi che il codice aderisca alla stessa formattazione, come se un foglio fosse nello stesso stile di scrittura, è necessario modificarlo e revisionarlo. Il codice dovrà essere ripulito, rivisto, rielaborato, ecc.

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

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

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

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

Il mio primo sforzo è stato di circa sessanta pagine (ha incorporato gran parte delle linee guida della struttura di Microsoft). Mi è stato chiesto di ridurlo, e il mio impegno successivo è stato di dieci pagine, utilizzando idee provenienti da una varietà di buone fonti. Mi è stato chiesto di ridurlo di nuovo, e alla fine lo ho ridotto a tre o quattro pagine, credo.

Non è mai stato adottato.

Perché? Perché lavoro con molte persone davvero intelligenti, che seguono già istintivamente uno standard di programmazione sensato.

Da parte mia, seguo le linee guida generalmente accettate da Microsoft ed emulare gli stili di uso comune degli altri (Javascript e jQuery sono formattato in modo diverso da C #, anche se sono entrambi lingue di parentesi graffa). Inoltre, infrango le regole di volta in volta, in questo modo renderò il codice più leggibile.

Se usi e IDE che fa le basi di ciò per te (Visual Studio per esempio), lascia che l'IDE faccia la cosa e qualunque cosa sembri ancora difficile da guardare modifichi finché lasci che l'IDE faccia ancora è una cosa o la prossima persona che auto-formatta lo ucciderà comunque.

Ciò che è più leggibile per una persona non 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 capire rapidamente il codice. Più simile è la formattazione del codice attraverso un progetto e tutti gli sviluppatori, più facile (e più inconsciamente) sarai in grado di lavorare con il codice.

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

Sebbene la leggibilità sia decisamente importante. Se i tuoi standard di formato del codice sono ben pensati e vengono utilizzati correttamente, potresti scoprire che puoi andare oltre la semplice lettura del codice e riuscire a capire il codice ancora più rapidamente.

Un insieme di linee guida che utilizzo durante lo sviluppo o l'aggiornamento dei nostri formati di codifica è il Gestalt Principles of Grouping - link

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

if(true)
{
}

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

Qualunque sia la lingua o lo strumento che usi, crea qualcosa. Configura il tuo IDE e controlla il file di configurazione.

Quando qualcuno controlla il progetto, useranno gli stessi stili di formattazione. Non importa quale sia lo stile, solo che è coerente. Ho le mie preferenze riguardo agli spazi v. Tabs, e su quale linea le parentesi graffe vanno avanti. Ma più delle mie preferenze, mi interessa solo che un dato file del codice sorgente sia d'accordo con se stesso. Lo rende molto più leggibile di quanto non sia un guazzabuglio derivante da una guerra formato.

La cosa peggiore che ho incontrato finora è l'assenza di standard di codifica. E ti è proibito rendere più leggibile un blocco di codice perché rompe gli strumenti diff ... Perché stiamo usando le patch per applicare le modifiche (modifica / richiesta di correzione bug - > correzione / modifica - > patch - > patch applicata da " trusted "person - > commit) puoi ottenere codice sorgente dall'aspetto piuttosto divertente (dal punto di vista della leggibilità). Almeno non abbiamo nessuno che usi due lettere (-.

[rant] La cosa più divertente è che tutti sono d'accordo sul fatto che dobbiamo cambiarlo. Ci sono stati anche un paio di tentativi di riformattare (automatizzato su commit), ma perché manca una singola minuscola opzione di formattazione bitsy - l'unica cosa che è riuscita a risolvere. 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 i costrutti if() o for(;;) devono essere seguiti da un blocco e non da una singola istruzione, rende esplicita l'intenzione del codificatore iniziale e aiuta i prossimi coder a mantenerla.

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

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

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

Tutto ciò detto, penso che la maggior parte delle squadre trarrebbe beneficio dall'accettare un modo standard per nominare variabili, funzioni e classi, parentesi di posizione e così via. Se la squadra non è d'accordo su qualcosa di così semplice, come possono aspettarsi di venire insieme e prendere le decisioni veramente importanti? Inoltre, la tua squadra non sarà composta dalle stesse persone per sempre - le persone se ne vanno, vengono assunte nuove persone. Più è facile per le nuove persone ingannare il codebase, più velocemente possono contribuire alla squadra senza abbassare la qualità del codice.