Quali sono le linee guida per la formattazione del codice generalmente accettate?

Question

Secondo Il modello della qualità di McCall, Revisione del prodotto è una delle tre prospettive principali per descrivere gli attributi di qualità di un prodotto software.Nella prospettiva della revisione del prodotto, manutenibilità, la capacità di trovare e correggere un difetto, è identificato come un fattore chiave di qualità che influisce sulla capacità di rivedere il software.

Chiaramente, ad un certo punto del processo di revisione, è necessario il coinvolgimento umano, in particolare il coinvolgimento dei programmatori.La formattazione del codice ha un impatto sulla capacità del programmatore di revisionare il software in modo efficace ed efficiente.

Con quali linee guida per la formattazione del codice, generalmente accettate e indipendenti dal linguaggio, hai lavorato per massimizzare l'efficienza e l'efficacia del programmatore nel processo di revisione del codice?

Answer 1

La migliore linea guida con cui abbia mai lavorato è la coerenza.Nel corso degli anni ho utilizzato molti stili diversi con team diversi...i risultati migliori che ho visto sono stati quando l'intera squadra è costretta a utilizzare lo stesso stile, indipendentemente dallo stile :-)

Answer 2

Ho alcune riflessioni su alcuni concetti indipendenti dalla lingua:

1.) Rimuovere il codice morto.A meno che qualcosa non sia assolutamente essenziale, il codice morto commentato dovrebbe essere rimosso.Confonde la routine, spesso ottieni falsi positivi quando cerchi qualche stringa e mostra una trascuratezza generale che non va bene per uno sviluppatore professionista

2.) Per le correzioni di manutenzione, fare riferimento a un numero di tracciamento dei difetti in un commento, presupponendo che si disponga di una sorta di sistema di tracciamento dei difetti.Ciò rende più semplice per chi si occupa della manutenzione del tuo lavoro capire perché il codice è stato modificato tra una revisione e l'altra.

3.) Per i linguaggi che lo supportano, dichiarare le variabili il più vicino possibile al loro primo utilizzo.

Sono sicuro che ci siano alcuni altri concetti indipendenti dalla lingua, ma questi sono i primi che mi vengono in mente.Per quanto ne so, è relativamente difficile discutere gli standard di codifica in assenza di un linguaggio specifico.E sono d'accordo con le altre risposte sopra: lo stile migliore è solitamente quello che si fonde meglio con lo stile esistente.

Potresti dare un'occhiata a Steve McConnell Codice completato.È pieno di buone idee che dovrebbero essere applicabili in quasi tutte le situazioni di sviluppo, indipendentemente dal linguaggio di programmazione.

Answer 3

La coerenza è la chiave.Annotare le linee guida da qualche parte e richiedere la conformità.

Non vale la pena preoccuparsi né discutere della formattazione del codice.Basta stabilire alcune regole e rispettarle.

Answer 4

Sono d'accordo con Gioele.Ci sono molti esempi di stile là fuori;la maggior parte sono buoni.Alcuni non sono più utili come altri (notazione ungherese?).Il punto centrale, però, è la coerenza.Finché un nuovo sviluppatore può entrare e comprendere subito il codice invece di doversi abituare allo stile personale di ogni singolo sviluppatore, funziona.

Cambiare standard ogni anno circa è probabilmente una cattiva idea.

Answer 5

Sono d'accordo con Joel, la manutenibilità aumenta considerevolmente quando c'è coerenza all'interno della tua organizzazione.Se mi unisco a un altro team, il tempo di accelerazione è molto inferiore se tutto ha un aspetto simile al mio attuale perché posso leggere il codice molto più velocemente senza tutto il "cambio di contesto interno" per orientarmi "così usano mVar invece di _var" / ecc

Answer 6

Uno dei grandi standard che abbiamo è il "prefisso" variabile.Fino al mio arrivo qui, avevo scritto per lo più da solo, quindi non me ne preoccupavo.

Siamo "richiesti" di denominare le variabili con prefissi che indichino cosa sono.Quindi, quando guardi dpVarName capisci immediatamente che è un puntatore a un double e che lVarName è un int lungo.

All'inizio ero contento che ci avessero dato due scelte per mettere i blocchi tra parentesi, ma ora vorrei che fossimo tutti costretti a farlo in un modo o nell'altro.