La mia squadra dovrebbe utilizzare uno standard di codifica comune ben considerato come base per il proprio?

In altre parole, ti stai chiedendo se è necessario iniziare subito gli standard di codifica della tua squadra prendendo in prestito standard esterni che hai trovato. Non sembra che qualcuno nel team abbia opinioni super-forti (ancora) su cosa dovrebbero essere quegli standard.

Inequivocabilmente, la risposta è sì.

Uno standard esternamente è superiore al nulla. Guarda le risposte in " link " per vedere alcuni dei vantaggi di avere uno standard. La coerenza e le basi per il cambiamento sono fondamentali dal tuo punto di vista.

Dai anche un'occhiata a " Gestione degli standard di codifica sul lavoro (io non sono il capo) " as entra in alcune delle dinamiche di squadra che la tua squadra deve prendere in considerazione quando seleziona quali dovrebbero essere gli standard. Il team deve possedere i propri standard di codifica in modo che tutti rispettino volentieri le restrizioni imposte al modo in cui ogni persona codifica.

Sei collegato a questa domanda, ma vale la pena sottolineare la risposta principale e concentrarsi sulla comprensione del perché i requisiti sono a posto Se utilizzi uno standard esterno, sarà difficile per il tuo team comprendere le basi dietro tutti questi requisiti. Ma se accetti di essere lì semplicemente perché il tuo team ha bisogno di qualcosa per iniziare, allora è facile passare a cambiare quello standard esterno a qualcosa che funzioni meglio per il tuo team.

Avere uno standard sul posto ti permette di popolare le regole di formattazione che userai con il tuo IDE (Eclipse nel tuo caso). " Vantaggi e svantaggi del codice forzato riformattato " entra nei benefici per tutti i membri del team per avere quella coerenza con il codice su cui stanno lavorando e ti dà la possibilità di riformattare i frammenti che potresti prendere in prestito da altri progetti. Un ulteriore vantaggio dell'utilizzo di uno standard esterno è che potrebbe essere già pre-compilato nella parte di formattazione del codice del tuo IDE.

Qualcuno della squadra probabilmente si lamenterà di una parte specifica dello standard e darà la colpa al fatto che tu abbia usato uno standard esterno come base. Invitali a leggere:
- Odio uno dei nostri standard di codifica e mi fa impazzire, come elaborarlo?
- Come si superano i propri errori di codifica quando viene passato il codice legacy?
e poi capire che probabilmente si sarebbero lamentati di qualcosa all'interno dello standard, non importa da dove venisse. Attraverso il numero di team su cui ho lavorato, devo ancora vedere uno standard che tutti a) sono universalmente apprezzati e b) concordato con ogni parte dello standard. Fai riferimento ad alcuni dei primi link per vedere come affrontare questi problemi.

Addendum, hai chiesto "quale dei due" dovresti usare. In particolare, non risponderò a questo dato che qualsiasi risposta è potenzialmente scatenata da guerre di fiamma alimentate dall'opinione pubblica. Tuttavia, puoi guardare il tuo IDE (Eclipse) e vedere quali opzioni fornisce come configurazione standard. Cercherò anche un po 'e vedere se ci sono progetti che si collegano al tuo IDE e fornisci opzioni standard aggiuntive tra cui scegliere. Giusto o sbagliato, questi standard sono già compilati per te e possono salvare un bel po 'di lavoro nella tua configurazione per tutti.

Vorrei iniziare con python. Python ha linee guida di programmazione che seguono quasi ogni singolo programmatore Python. Fanno parte della documentazione ufficiale denominata PEP8 .

C / C ++ è un enorme casino per ragioni storiche, ma dal momento che Python non lo è, ti consiglio di seguire anche la convenzione di denominazione Python in C / C ++ per motivi di coerenza.

Ora per C ++ è più importante concordare su idiomi comuni e assicurarsi che tutti comprendano lo stile C ++ moderno ragionevole di qualsiasi guerre sulle convenzioni di denominazione. Dovresti iniziare con Standard di codifica C ++ e dalle risorse online assicurati di leggere Domande frequenti su C ++ .

Non puoi nemmeno discutere questo argomento senza fare la distinzione tra uno standard di codifica e uno lo standard di stile di codifica .

Uno standard di codifica è un insieme di regole che definiscono quali meccanismi linguistici sono autorizzati a utilizzare, quali non sono autorizzati a utilizzare e come usarli. In altre parole, definisci un sottoinsieme della lingua utilizzata e / o un superset, se lo standard di codifica soddisfa determinate estensioni non standard.

Uno standard di stile di codifica riguarda solo i problemi estetici: dove posizionare le parentesi graffe e gli spazi, come denominare gli identificatori, come posizionare i commenti, ecc.

Queste due cose diverse potrebbero trovarsi nello stesso documento. Tuttavia, il più serio degli standard di codifica non riguarda se stessi con stile - quelli che raccomando di seguito non lo fanno. Molto probabilmente perché lo stile di codifica è molto soggettivo e quindi causa un sacco di attriti quando le opinioni si scontrano.

Per C / C ++, gli standard di codifica con la migliore reputazione sono quelli di MISRA . Sono progettati principalmente per applicazioni di sicurezza / mission-critical, ma poiché la chiave per rendere i programmi più sicuri è rimuovere ed evitare bug, gli standard MISRA si applicano a qualsiasi ramo di programmazione in cui i bug non siano desiderati.

Gli standard da CERT sono anche abbastanza noti e più orientato verso la programmazione desktop e la sicurezza del software (piuttosto che la sicurezza). CERT ha standard per C, C ++, Java e Perl, e gli standard sono gratuiti.

Vorrei iniziare guardando MISRA e CERT, piuttosto che alcuni standard di garage casuali trovati sul web.

L'utilizzo di uno standard esistente come base per il tuo ha diversi vantaggi. Il tuo codice sarà probabilmente più simile al codice esterno, rendendo più facile la lettura / integrazione del codice. Inoltre, se scegli un buon standard, questo sarà stato esaminato da esperti che hanno avuto buoni motivi per decidere le loro regole particolari. Fintanto che nessuno della tua squadra è particolarmente legato a uno standard, ci sono poche ragioni per non utilizzare uno standard esistente come base per il tuo.

Se non sei sicuro di quali standard di codifica usare, ci sono alcune ovvie scelte ideali. In nessun ordine particolare:
1. Qualunque sia lo standard è già supportato dal tuo IDE. Questo è probabilmente configurabile.
2. Indipendentemente dallo standard utilizzato / consigliato dall'autore del compilatore.
3. Indipendentemente dallo standard utilizzato / consigliato dall'autore del tuo framework primario (se ne esiste uno).
4. Indipendentemente dallo standard utilizzato / consigliato dall'autore / dai designer / dai designer del tuo linguaggio di programmazione.
5. Qualunque sia lo standard utilizzato / consigliato da una società molto grande.

Raccomando a qualcuno con esperienza tecnica di leggere qualsiasi standard tu stia utilizzando come base per il tuo standard. Un buon standard avrà spesso una giustificazione per ogni regola, che ti aiuterà a modificare lo standard per soddisfare al meglio le tue esigenze.

Normalmente uno standard aiuta la comunicazione e la manutenzione. Secondo me, dovrebbe essere soggetto a dare e avere, specialmente in piccoli gruppi, e dovrebbe evolversi. Chiamarli linee guida può aiutare: -)

Dai un'occhiata alle linee guida di Google per l'ispirazione.

NO, non mi preoccuperei - penso che l'unico vantaggio sarebbe se la tua squadra si trasferisse in un posto in cui erano stati usati anche quegli standard, che non è quello che vuoi che succeda:)

Gli standard sono lì solo per incoraggiare una collaborazione più semplice, quindi se sai che una macro #define è sempre in maiuscolo, quando vedi un identificatore in maiuscolo nel codice, avrai una buona idea di una macro. Allo stesso modo, altre convenzioni di denominazione o convenzioni di stile ti ricorderanno ciò che stai trattando.

Trovo che gli standard come la posizione e il nome dei file siano più utili1 di quelli di codice (dopotutto, il codice ha tutte le forme e le dimensioni e devi ancora leggerlo) mentre non si conosce readme.txt in / bin / doc / debug / release / documents è un vero dolore (come un percorso così schifoso, ma questa è un'altra storia).

Ti consiglierei di mettere su i tuoi standard mentre vai avanti. In questo modo, non solo ottieni quelli che ti piacciono, ma ne ottieni quelli che sono sicuramente adatti a te, alla tua squadra e al lavoro che fai. Se decidi che non ti interessa davvero come appare un ciclo, o che le dichiarazioni del caso devono essere rientrate in un certo modo, allora stai bene. Se decidi che gli operatori ++ sono vietati, anche questo è buono. Tutta la tua scelta

Dovresti renderlo più facile da trovare e aggiornare, una wiki o una pagina web generata automaticamente da una descrizione testuale, ma in caso contrario ... vai avanti. Gli standard hanno un atteggiamento mitico da parte di alcune persone che sono più interessate a seguire fanaticamente lo standard che a scrivere un buon codice, non essere come loro: crea il tuo standard che ti aiuta dove ti serve.