In risposta a Questa domanda , I chiedi: quali sono le parti migliori del tuo standard di codifica?
Quali sono le migliori pratiche che aiutano con la qualità del codice, l'affidabilità, la manutenibilità, la leggibilità, ecc.
Si prega di includere la lingua, l'elemento dallo standard e il motivo per cui migliora il codice.
All Languages: Write readable code instead of comments
Confronta questo:
public void update() {
// Fetch the data from somewhere
lots of lines of;
code;
for;
fetching;
data;
from somewhere;
// Sort the data
more lines of;
code;
which sorts;
stuff;
around;
a bit and then;
// Update the database
lines of code;
which uses;
some lib;
to update;
using iteration;
and logic;
the database;
done;
}
Con questa versione in cui i commenti vengono sostituiti con le chiamate di funzione:
public void update() {
data = fetchData();
sorted = sortResults(data);
updateDatabase(sorted);
}
Solo una classe pubblica deve essere inserita in ogni file, non di più.
Qualsiasi lingua:
Un uso adeguato e coerente degli spazi bianchi, sia verticale che orizzontale, ampiamente migliora la capacità del codice di essere rapidamente scremato e di leggere a un ritmo normale. Non ho intenzione di discutere sulle schede rispetto agli spazi, purché il loro utilizzo sia coerente, ma sono assolutamente necessari indentazione e uso giudizioso di linee vuote e spazi attorno agli operatori.
Correlati: mantenere le lunghezze delle righe a un limite ragionevole come 80 colonne ha vantaggi dimostrabili: nessun involucro strano su console, nessuna necessità di scorrere e la possibilità di visualizzare più file affiancati su un ampio monitor, per non parlare di quello tende a incoraggiare il refactoring del codice profondamente annidato e delle espressioni run-on.
Ad esempio:
public class ClassNamesArePascalCase{
public int FieldsArePascalCase;
private int _privateFieldsAreUnderscoredCamelCase
public const int CONSTANTS_ARE_CAPITAL = 3;
public void MethodNamesArePascalCase( string parametersAreCamel ){
int localVariablesAreCamel;
}
}
Non importa tanto quali standard usi per quali tipi di nomi, purché coerenti tra loro (ad esempio, tutte le costanti sono maiuscole), coerenti all'interno del progetto e diverse l'una dall'altra. Il vantaggio qui è che posso dire a colpo d'occhio che _someVar è un campo privato senza doverlo cercare.
C : le "funzioni" macro del preprocessore dovrebbero essere tutte maiuscole
Esempio: #define CUBE(x) ((x)*(x)*(x))
Motivo: quando si esegue la scansione del codice, i macro si distinguono dalle normali funzioni e avvisano che potrebbero verificarsi effetti indesiderati che una normale chiamata di funzione non avrebbe mai avuto, come la modifica del valore dell'argomento "input" o la valutazione di 3 volte.
In Java.
Questo significa che le modifiche al codice sorgente sono registrate al primo commit in seguito, invece che in un secondo momento quando viene eseguito un reformat. Ciò è positivo quando si effettuano indagini "quando questo è cambiato".
Non usare mai la notazione ungherese. In tipi staticamente i linguaggi non sono necessari e nelle lingue digitate dinamicamente è quasi sempre dannoso. Inoltre, Notazione ungherese è l'arma nucleare tattica delle tecniche di offuscamento del codice sorgente .
C #: utilizza il metodo di estrazione anziché i commenti
Se pensavamo di dover aggiungere un commento a un blocco di codice per spiegare che cosa sta facendo, dovremmo invece estrarre quel codice in un nuovo metodo con un nome descrittivo.
Questo rende il codice più leggibile e modulare e riduce il numero di commenti (non aggiornati) che galleggiano.
Formattazione - in particolare Rientro! Sto usando Delphi e la prima cosa da fare quando ottengo il codice non formattato per il mio utilizzo lo riformattare. In questi casi, il formattatore integrato in Delphi funge da una delle funzioni più utilizzate.
COERENZA
Non sono infastidito da alcuna particolare convenzione di denominazione o codifica (anche se, ovviamente, ho delle preferenze) a patto che qualsiasi codebase a cui sono applicate usi queste convenzioni in modo coerente.
Ho letto Pulisci codice ultimamente e trovo che mi ha aiutato un po '( anche se non sono d'accordo / l'uso di tutti).
Per l'ereditarietà di C ++. Sottolineando ciò,
Per altre cose.
C # e Java:
Abbiamo usato una convenzione di denominazione per i nostri elementi del database.
Spesso dovremmo creare un widget per un cliente e 3 mesi dopo lo rivenderemo a un altro cliente. Alla fine sono sorti conflitti di denominazione e abbiamo dovuto ricodificare un widget.
Ad esempio:
Widget di comunicato stampa
Widget Galleria foto
Se il Cliente-A aveva già il widget del comunicato stampa e ora desiderava il widget Galleria fotografica, si è verificato un conflitto di denominazione con tblCategories. Non potevamo semplicemente creare script sugli elementi della Galleria fotografica ed eseguirli contro il database di Company-A. Argh!
Quindi abbiamo iniziato ad aggiungere un "widget" riferimenti ai nostri elementi SQL:
Ciò ha mantenuto le cose ben impacchettate e ci ha aiutato a essere più redditizi a lungo termine.
Il metodo di denominazione univoco, non ha importanza sulla lingua. Ad esempio .. G = Globale, L = Locale, P = Parametro. Ora, quando hai una variabile come G_strFoo, so che la sua definizione può trovarsi nel mio file globale. Aiuta a stare al passo con tutte le variabili nei miei programmi.
In Python, usa solo la libreria standard, e se non puoi evitare di usare un'altra libreria, spiega perché da qualche parte. Un giorno potrebbe essere necessario sostituire la lib e sarebbe bello sapere da dove cominciare.
Inoltre, tienilo molto molto semplice.
Ho scritto di questo nel mio blog l'altro giorno.
Convenzioni e standard di codifica C #
Penso che per quanto riguarda le convenzioni di codifica, la cosa principale che contribuisce all'affidabilità, alla manutenibilità e alla leggibilità del codice sono le convenzioni di denominazione. Il resto del materiale è piuttosto standard.
Non esiste un modo "giusto" o "sbagliato" con le convenzioni di denominazione. La chiave è la coerenza. Ad esempio, utilizzo sempre camelCasing per parametri e variabili locali, utilizzo camelCasing con prefisso con un underscore per i membri del campo privato / protetto e utilizzo PascalCasing per nomi di classi, proprietà, eventi, funzioni, ecc.
In generale, mi rifaccio anche alla notazione ungherese per motivi di leggibilità, ma penso che in alcuni scenari sia utile (di solito uso la notazione ungherese per i tipi di GUI).
Un effetto collaterale del rispetto delle convenzioni è che è facile tenere traccia del tipo di identificatore che si sta guardando durante la lettura del codice. Ad esempio, posso sempre contare sul fatto che le proprietà utilizzano PascalCasing mentre le variabili locali no, il che mi impedisce di dover eseguire la scansione e trovare la definizione di un identificatore durante la lettura del codice.
Il fatto che il tuo team segua le stesse convenzioni e standard di codifica può aiutarti a rendere il tuo software più leggibile e più uniforme mantenendo le cose coerenti e pulite. Ciò facilita la manutenzione consentendo ai membri del tuo team di leggere e comprendere il codice scritto dai collaboratori più rapidamente senza dover eseguire mentalmente un filtro in background per interpretare le differenze di layout e stile, ecc. Inoltre promuove le best practice e può contribuire a mantenendo le tue API coerenti pure.
Se il tuo codice è pulito, coerente e di facile lettura, diventa più gestibile e meno soggetto a errori.
Leggi altre domande sui tag coding-standards