Dovremmo incoraggiare gli stili di codifica a favore dell'autonomia dello sviluppatore, o scoraggiarlo a favore della coerenza?

Un documento standard di codifica è utile. È più utile quando è abbastanza breve da permettere a chiunque di ricordare l'intera cosa senza troppi problemi e quando non causa nessuno troppo dolore.

Il modo in cui scegli di riordinare il codice nella tua organizzazione, o capitalizzare i nomi, o implementare i tuoi loop, o commentare il tuo codice non è poi così importante; la parte utile è far sì che tutti scrivano il codice che sembra lo stesso di tutti gli altri.

• Evita di dover trascorrere un minuto a ricalibrare le tue aspettative su dove dovrebbero essere le parentesi graffe e ogni volta che guardi il codice di qualcun altro.
• Evita di avere diversi stili di codice nello stesso file.
• Forse la cosa più importante, avere uno standard scritto evita argomenti sulle pratiche di codifica durante le revisioni del codice.

Ancora una volta, quali sono gli standard non importa quanto avere una sorta di standard semplice e diretto. Quindi, metti tutti i tuoi sviluppatori in una stanza e lascia che discutano su quali dovrebbero essere gli standard. Questa riunione potrebbe continuare all'infinito, quindi le regole sono:

• Tutto ciò che non è deciso entro la fine della riunione verrà deciso dal gestore.
• L'incontro si concluderà dopo due ore o quando qualcuno inizia a gridare oa piangere, a seconda di cosa viene prima.
• L'intero standard si adatta (in dimensioni ragionevoli!) su un foglio o due di carta, a doppia faccia solo se assolutamente necessario.

Considera l'adozione di qualcuno | altro | standard come punto di partenza per la tua riunione sugli standard di codifica , o come un modo per evitare completamente l'incontro.

Una volta concordato, gli sviluppatori dovrebbero essere in grado (e dovrebbero essere tenuti a) di autogestirsi. Deviazioni occasionali dallo standard non dovrebbero essere un grosso problema (e potrebbero anche essere giustificabili), ma il rifiuto sconsiderato di abbandonare uno stile personale preferito a favore dello standard dovrebbe comportare il trasferimento immediato in ufficio con le condutture dell'acqua che perdono, o qualsiasi altra cosa .

Demian Brecht punta a strumenti per sfilacciare. Questi sono un complemento perfetto per un documento di standard di codifica. È semplicemente buono attenersi agli standard di stile di codifica; è importante attenersi agli standard di codifica relativi alle pratiche pericolose. Nessuno oltre all'autore verificherà che ogni linea di codice soddisfi lo standard per lo stile, ma dovresti sicuramente considerare la possibilità di creare uno strumento di sfilacciamento nel flusso di lavoro del tuo team per rilevare automaticamente i probabili bug. Inoltre, lo strumento stesso può codificare le pratiche accettate in modo che non sia necessario elencarle singolarmente negli standard di codifica; basta specificare la configurazione dello strumento.

Nota: l'idea di "standard di codifica" non è esclusiva della programmazione. Gli "standard di codifica" sono usati in molti campi, a volte all'interno di un'organizzazione, più spesso in un intero settore o professione. Alcuni esempi:

• Documenti legali come documenti giudiziari e trascrizioni aderiscono a formati specifici.
• Gli script e le sceneggiature devono essere scritti in uno stile particolare per poter essere presi sul serio.
• I disegni tecnici spesso devono avere un cartiglio in formato standard.
• I formati Bibilography sono standardizzati.

In ciascun caso (e molti altri) un professionista competente potrebbe facilmente capire "codice" che non soddisfa lo standard previsto. Perché così tante industrie continuano a scrivere requisiti dettagliati per i documenti che non hanno nemmeno bisogno di essere analizzati da un compilatore? Perché lo stile è importante . Presentare informazioni in uno stile standard consente al lettore di concentrarsi interamente sul contenuto, rende la lettura più veloce e aiuta a comprendere e riduce gli errori.

Lo stile non ha importanza.

Ecco, l'ho detto.

Dopo 30 anni e centinaia di siti client e codice da (stimare) 500 (o più) membri del team in quegli anni, ho trovato che lo stile non ha importanza.

Falla funzionare, innanzitutto.

Scaricalo per utilizzare un volume ottimale di risorse (ad es. struttura dati corretta, algoritmo giusto).

Fuss over "style" dopo che tutto altro è stato risolto. Fuss di "stile" solo con strumenti, mai manualmente.

Ci sono stili di codifica e ci sono odori di codifica. Non è stato una volta che ho trovato:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Il mio precedente datore di lavoro ha rigorosamente vietato l'uso di multiline if() senza parentesi graffe. È stato considerato un errore di tipo "fallo di nuovo e sei licenziato". I costrutti consentiti erano

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

Questo è il risultato di un errore proprio come quello che ho mostrato sopra, che impiegò un paio d'ore per trovare la fine della pagina principale del portale.

Ci sono cose che dovresti sempre fare. Mi piace switch() :

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

Nel frattempo, digitando:

     case 1:
         something();
     case 2:
         something();
     break;

senza chiudere un case con //fallthrough è considerato un bug.

In generale, c'è lo standard di codifica che è la linea guida che può essere ignorata, interpretata in modo creativo o modificata per esigenze specifiche. E c'è la sezione sugli "odori" e deve essere rispettata rigorosamente.

Crea coerenza con un buon design iniziale. Quello che descrivi nella domanda non è altro che micro-gestione. Faccio un sacco di sviluppo web. Quindi preferisco lo sviluppo RESTful e CRUD esposto come servizi. Ciò garantisce entità semplici e ben definite che possono essere utilizzate in vari modi.

Questo design mi consente anche di delegare dettagli di implementazione ad altri sviluppatori. In questo modo riempiono gli spazi vuoti anziché creare un intero progetto di sistema.

La mancanza di un design complessivo crea incoerenze di sistema. La critica delle iterazioni di base e dei costrutti di loop fa poco per migliorare la progettazione del sistema. Questi tipi di problemi sono risolti meglio con un approccio "hands off", StyleCop.

È possibile disegnare un diagramma relativamente semplice della progettazione generale del sistema? Un design che descrive gli elementi / entità coinvolti in un nuovo sviluppatore di team. Se non puoi, o è molto coinvolto, il design è carente.

IMHO dipende ...

I tuoi primi due esempi non sono solo una questione di gusti personali per me.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(senza parentesi) = più incline ai bug, se più codice viene aggiunto in seguito:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

E questo è meno conveniente per il debug:

new HelperClass().DoSomething(GetSomeData()); // etc.

Non puoi semplicemente impostare un punto di interruzione dove ti serve. Se questo è un one-off - abbastanza giusto, ma lo discutiamo come una questione di stile, e una volta che hai roba del genere dappertutto, il debug diventa più spiacevole di quello che deve essere.

Per quanto riguarda il tuo terzo esempio (per vs foreach), lo vedo comunque come una questione di gusto.

Nessuno dei due. Eviterei le rigide regole di codifica per evitare di essere noioso, pignolo, micro-manageriale e, peggio di tutto, perdere tempo. Il tuo senso di autonomia è il tuo problema. Se voglio che tu ti senta meglio con te stesso, ti offro un giro della tua bevanda preferita. Oltre a questo, fai qualcosa.

L'uso di convenzioni, nomi di variabili, nomi di classi ecc. è una buona pratica. Ma gli stili di codifica come gli esempi forniti sono piuttosto banali e non hanno alcun effetto sulla leggibilità o sull'efficienza del codice. D'altro canto, l'overhead dovuto all'applicazione di uno stile dato combinato con lo sforzo degli sviluppatori di seguirlo causerà problemi.

Utilizza uno strumento di linting standard del settore (apparentemente FxCop per C #). Benché non sia la soluzione definitiva, be-all, la coerenza è importante in progetti di grandi dimensioni con un numero di persone che lavora su di essi.

Se stai solo lavorando su un tuo progetto o una piccola squadra, molti potrebbero obiettare che è eccessivo. Io credo diversamente (io uso PEP8 per Python, anche nei miei progetti personali per sviluppatori singoli).

La maggior parte degli esempi che hai fornito, tuttavia, molto probabilmente non saranno catturati da uno strumento di sfilacciamento poiché semplicemente non hanno importanza.

Applicare uno stile di codifica uniforme è sempre difficile. Idealmente, questo compito banale dovrebbe essere lasciato a uno strumento da gestire. Apprezzo la comunità linguistica Go per farlo.

È una miscela di entrambi. Solo perché è uno standard non lo rende leggibile e mantenibile. Se non c'è ancora uno standard instillato, o ci sono aspetti difettosi e illeggibili, la revisione è appropriata.

Nell'analisi finale, è il programmatore che guida la programmazione. Esistono problemi di stile, ma sono secondari per far uscire il programma.

È utile dare ai programmatori qualche indicazione di stile. Questo può / dovrebbe essere fatto prima che i programmatori siano messi al lavoro, specialmente se sono relativamente principianti all'ambiente, o alla programmazione stessa. In base a una guida, alcuni programmatori saranno molto attenti allo stile, altri meno. Le indicazioni fornite all'inizio del progetto aiuteranno il primo gruppo di programmatori, rendendo così più semplice il compito complessivo. Potrebbe fare ben poco per il secondo gruppo, che (si spera) trarranno nella creatività, ciò che manca loro in conformità.

Penso che dipenda dalle dimensioni del progetto e da quante persone ci stanno lavorando. Un programmatore esperto può esaminare entrambi gli stili di formato differnt e sapere cosa stava succedendo in entrambi, ma è necessario un vincolo in modo che l'occhio possa catturarlo facilmente. Se stai andando a fare i tuoi ifstat a linea singola senza le parentesi graffe, quel progetto non dovrebbe usarli Chiunque stia conducendo quel progetto dovrebbe avere quella scelta. Mi piacciono le cose per apparire nitide e anche molto compatte come posso farle. Se stai andando a fare una singola riga se statmeents sono meglio così

if() {}
else() {}

O anche:

if() {} else () {}

Ma una singola riga se non dovrebbe usare la spaziatura di un mulitiline se. È solo come faccio le cose. Non mi interessa il modo in cui viene chiamato l'oggetto e ciò dipende da quante volte è chiamato. se viene richiamato un paio di volte, allora avvio piuttosto l'oggetto e dipende se ha dei costruttori e cosa no. Perché se hai un costruttore e chiami:

Object.method();
Object.method2();

Quindi hai finito per chiamare due volte il metodo del constuct object quando avrebbe potuto essere evitato istanziando completamente l'oggetto.

Quando si tratta di foreach e for loops Anche per quanto riguarda la lanauge alcuni lanauges ti danno un controllo migliore quando guardi l'array in un ciclo foreach così hai la chiave e il valore in array temporanei. E so che alcuni canali hanno una sorta di ottimizzazione perché possono guardare il ciclo e sapere esattamente quante volte verrà chiamato.

Anche se il tuo primo esempio non è eccezionale (l'argomento che è più soggetto a correzioni di bug comporta un certo peso), in generale sono cresciuto a preferisco che gli sviluppatori usano stili di codifica leggermente diversi.

Dopo aver lavorato con il codice di altri membri del team, a volte per pochi mesi, in sostanza inizia a lavorare in linea con un git blame . Dopo essere stato nella mia azienda per oltre 10 anni, posso probabilmente dirti con una precisione dell'80% + che ha scritto una determinata classe in qualsiasi punto delle nostre linee di codice da 500k, semplicemente osservandola.

Mentre c'è un po 'di "tempo di rampa" quando si inizia a guardare il codice che usa uno stile con cui non si è d'accordo, quello che stai facendo in quel momento sta dicendo "oh, questo sembra John Doe's codice (perché usa lo stile X ma non lo stile Y, ecc.) ". E questo porta con sé un intero mucchio di contesto. In una prima approssimazione, sai cosa aspettarti dal codice di John - quali altre parti del codebase capisce bene e quali parti non lo fa, se è un guru SQL o un novizio della GUI, ecc. Ecc.

L'esecuzione del codice di tutti tramite un formattatore sostanzialmente estrae queste informazioni, nascondendole dietro un git blame , che potresti non preoccuparti di eseguire.

Questo dipende molto dal tipo di organizzazione.

Se sei un piccolo gruppo di supereroi, allora qualsiasi tipo di stile va bene. Se ognuno ha il proprio stile, ed è sia buono che internamente coerente, allora è tutto il processo che ti serve. I supereroi diranno: "Jane ha parentesi, quindi questo è ciò che intende" o "Jack usa camelCase per le variabili".

Gli standard universali tendono ad essere i migliori per rendere tutti giocatori B +. I tuoi supereroi saranno abbattuti da questo. Ma se vuoi un giocatore A e una mezza dozzina di giocatori B e una mezza dozzina di giocatori C fare la media fino al B +, allora vuoi degli standard coerenti. In questo caso, vuoi che tutti facciano le cose allo stesso modo in modo che l'unico giocatore A possa attraversare il codice di tutti il più rapidamente possibile.

Molti di voi "Ma aspettate, perché non eliminare i giocatori di B e C?"

La realtà è che non ci sono molti Supereroi. Sebbene possa pagare per trovarli e nutrirli su Google, l'inserimento di un nuovo sistema di fatturazione per Ma Bell potrebbe essere più conveniente con quest'ultima squadra. (E se hai davvero Supereroi, 4 o 5 di loro saranno due volte più costosi di una dozzina di juniores)