Qual è un ragionevole livello di dettaglio per una guida di stile? [chiuso]

5

Stiamo sviluppando software embedded per un prodotto automobilistico in ANSI-C in un grande team. Ieri, nella nostra normale revisione del codice, abbiamo avuto una discussione generale sullo stile del nostro codice. Abbiamo una linea guida di codifica (circa 30 pagine), che garantisce principalmente alcune pratiche richieste e inoltre tratta la notazione ungherese, il livello di indentazione, la strategia di nuova riga per i blocchi di codice ecc.

La discussione di ieri riguardava l'eventuale necessità di linee guida più dettagliate su come il codice è stato formattato. Dichiarazioni di esempio:

int int1,
    int2 = 0;
short short1;
long_type_name_defined var1;
const * type var2;
type const* var3;

Un collega ha espresso il parere che ci dovrebbe essere una chiara linea guida su come allineare coerentemente le variabili (es .: spazi fino al tipo regolare più lungo), se ci dovrebbero essere spazi tra "*" e tipo / qualificatore, dove si trova il qualificatore, se usare o meno l'operatore ",", ecc. Cose che potrebbero essere in qualche modo dichiarate come una questione di gusto personale.

Pro:

  • aumento della leggibilità
  • meglio comprendere per "esterni" (che sono nuovi per il codice o che normalmente non ne fanno uso)

Contro:

  • perché è in qualche modo una questione di gusti personali, ciò che aumenta la leggibilità per una persona, potrebbe ridurla per un'altra (?)
  • potrebbe essere difficile definire chiaramente
  • il set di regole di stile sarebbe stato ampliato molto
  • molto lavoro per seguire sempre un ampio set di regole

La domanda principale è in qualche modo: Aiuta davvero avere una serie di regole molto specifica? Non siamo riusciti a trovare un chiaro consenso al riguardo. Una guida di stile dovrebbe aumentare la leggibilità / manutenibilità del codice, quindi ci sarà un ottimo rapporto tra dimensione del set di regole e "bellezza" del codice (?).

Mi piacerebbe avere le tue opinioni su dove sia questo optimum.

    
posta Jakob S. 21.05.2015 - 08:50
fonte

2 risposte

4

Does it really help to have a very specific rule set?

No. Francamente, no. Oppure, per dirla in modo più costruttivo, dai un'occhiata a qualsiasi codice sorgente di github o sourceforge, puoi leggere tit? Se la risposta è "sì", hai appena dimostrato che un singolo stile non è importante per la leggibilità.

Ciò che aiuta la leggibilità è un codice leggibile, che può sembrare sciocco, ma è spesso molto semplice da descrivere senza regole estese - l'uso giudizioso di spazi bianchi, rientri e righe vuote rende il codice leggibile. Cramming tutto insieme per utilizzare il minor numero possibile di tasti è l'antitesi di leggibile.

Quello che ho trovato è che le guide di stile estensive semplicemente non vengono seguite. 30 pagine sono pazzesche - devi dedicare più tempo a capire se stai seguendo la guida piuttosto che imparare il codice! E così anche tutti quelli che recensiscono il codice, e anche allora le persone mancheranno solo le parti. (anche se può essere soddisfacente quando il più accanito sostenitore dell'ampia guida di stile sbaglia il proprio codice)

La migliore guida che io abbia mai visto ha semplicemente detto "assicurati che il tuo codice abbia lo stesso aspetto del codice su cui stai lavorando". È facile da seguire, ed è ovvio dove si sbagliano, si distinguono come "diversi". Non importa quale sia lo stile originale utilizzato, purché coerente.

Ora, per "esterni": le guide di stile non aiutano qui. A chi importa quanti spazi hai messo di fronte a una dichiarazione variabile? Tali banalità non contano. Che cosa aiuta però è il layout - se le dichiarazioni sono sempre poste in cima a una funzione o classe, allora i neofiti sapranno dove cercare per trovare le variabili. Se la convenzione di denominazione dei file ha alcune regole, sarà facilmente in grado di trovare il codice dell'interfaccia utente poiché sarà sempre in un file chiamato "customerUI.c" (per esempio). Piccole cose del genere contano molto più di qualsiasi stile.

Si potrebbe dire "la struttura è ciò che gli standard fanno rispettare, lo stile deve solo essere di uno standard minimo"

    
risposta data 21.05.2015 - 10:03
fonte
2

Penso che sia abbastanza chiaro che uno stile di programmazione coerente può aiutare alcune cose specialmente se stai pubblicando il tuo codice.

  • Impedisce lo stile insolito
  • Differenza del codice limitato tra le versioni al momento del check-in per il controllo del codice sorgente
  • Lo stile coerente su un ampio codice di base semplifica la comprensione

Tuttavia, direi che è decisamente una cosa costosa da avere. Hai costi extra rispetto a un'azienda che non applica uno stile di codifica.

  • Nuovo Dipendente, tempo trascorso a leggere / imparare lo stile (tutte le aziende hanno stili diversi)
  • Senior dev, tempo trascorso a scrivere lo stile
  • Senior dev, tempo impiegato a mantenere lo stile wiki / sharepoint
  • Senior dev, tempo impiegato per forzare lo stile
  • Team, tempo trascorso a discutere sullo stile
  • Team, tempo impiegato a digitare cose extra richieste dallo stile (cioè il formato dei commenti, ecc.)
  • DevOps, tempo impiegato per far sì che l'elemento della configurazione imponga lo stile

Forse l'unica eccezione è dove usi uno strumento automatico come style cop per modellare automaticamente il tuo codice. In tal caso, se accetti solo le regole predefinite, puoi ottenere uno stile abbastanza coerente con un paio di clic.

    
risposta data 21.05.2015 - 10:18
fonte

Leggi altre domande sui tag