Il mio team dovrebbe usare alcuni standard di codifica ben considerati comuni come base per i propri?

Il team di ricerca e sviluppo in cui mi trovo ha deciso di adottare uno standard di codifica. Ci siamo formati solo di recente e abbiamo troppo poco tempo di programmazione e codice comune per basare i nostri documenti sulle norme / convenzioni su ciò che è stato sviluppato organicamente nel nostro team e su buoni esempi del nostro codice, ecc.

Ora, ognuno di noi ha una certa esperienza nei luoghi di lavoro passati - anche se nessuno di noi è in uno stato di affermazione "adottiamo questo documento completo qui che ho trovato adatto al tipo di lavoro che facciamo qui" (*). Inoltre, alcuni di noi (incluso me stesso) hanno esperienza solo in luoghi senza standard di codifica ufficiali o scrivono in lingue diverse in un ambiente diverso (ambiente di produzione a rilascio settimanale ad alta pressione rispetto a un lavoro di sviluppo più orientato alla ricerca)

Quindi, una delle opzioni a cui ho pensato è quella di prendere un documento relativamente noto e ben considerato, eliminare ciò che non ci interessa / prenderci cura e apportare alcune modifiche in base alle nostre preferenze.

È una pratica comune? Credi che sia una buona idea? In tal caso, quale sarebbe uno standard di codifica "baseline" ragionevole (non dirmi quale sia la cosa migliore, non voglio iniziare qui un conflitto religioso; sottolinea solo cosa sarebbe abbastanza completo o "neutrale" su cui basarci .)

Appunti:

• Ci aspettiamo di lavorare con C, C ++, OpenCL, CUDA, Python.
• Siamo un team di 4 persone + manager, che dovrebbe crescere fino a circa 5-6 entro un anno circa.
• Nella nostra azienda, i team sono quasi completamente autonomi e di solito non interagiscono affatto (nemmeno usando il codice reciproco - il lavoro è su progetti completamente diversi); quindi - nessuna considerazione a livello aziendale da fare.
• Per quanto riguarda gli strumenti, al momento quello che sappiamo è che useremo Eclipse , quindi il suo formattatore di codice sarà almeno uno strumento. Ctrl + Maiusc + F è stato a lungo mio amico
• Quando scrivo Java, ho adottato la pratica di aderire il più rigorosamente possibile all'efficace Java di Bloch . Ora, questo non è proprio uno standard di codifica, ma potresti chiamare alcuni mattoni, cemento e malta per uno standard di codifica. Stavo pensando di includere qualcosa del genere come parte del 'mix' (pensando che non facciamo Java).
• Voglio dire standard di codifica nel senso più ampio del termine, ad esempio, l'adozione di proposte avanzate nelle risposte a questa domanda P.SE .
• Ho trovato un grande elenco di documenti sugli standard di codifica C ++ ; forse dovrei minare quella nostra base.
• (*) Non è del tutto vero, ma non voglio complicare questa domanda con troppi dettagli.

Detto in altro modo, ti stai chiedendo se dovresti far ripartire gli standard di codifica del tuo team prendendo in prestito gli standard esterni che hai trovato. Non sembra che nessuno del team abbia opinioni (ancora) molto forti su quali standard dovrebbero essere.

Inequivocabilmente, la risposta è sì.

Uno standard di provenienza esterna è superiore a nulla. Guarda le risposte in " https://softwareengineering.stackexchange.com/q/84203/53019 " per vedere alcuni dei vantaggi di avere uno standard. La coerenza e la base per cambiare sono fondamentali dal tuo punto di vista.

Dai anche un'occhiata a " Gestire gli standard di codifica sul lavoro (non sono il capo) " in quanto entra in alcune delle dinamiche di squadra che il tuo team deve considerare quando seleziona quali standard dovrebbero essere. Il team deve possedere i propri standard di codifica in modo che tutti rispettino volentieri le restrizioni che impone su come ogni persona codifica.

Ti sei collegato a questa domanda, ma vale la pena sottolineare la risposta migliore e il suo focus sulla comprensione del motivo per cui i requisiti sono in atto. Se si utilizza uno standard esterno, sarà difficile per il proprio team comprendere le basi alla base di tutti questi requisiti. Ma se accetti che ci sono semplicemente perché il tuo team aveva bisogno di qualcosa con cui iniziare, allora è facile passare a cambiare quello standard esterno in qualcosa che funzioni meglio per il tuo team.

Avere uno standard in atto ti consente di popolare le regole di formattazione che utilizzerai con il tuo IDE (Eclipse nel tuo caso). " Vantaggi e svantaggi della riforma del codice forzato " vanno a vantaggio di tutti i membri del team per avere quella coerenza con il codice su cui stanno lavorando e ti danno la possibilità di riformattare frammenti che potresti prendere in prestito da altri progetti. Un ulteriore vantaggio dell'utilizzo di uno standard esterno è che potrebbe già essere precompilato nella parte di formattazione del codice dell'IDE.

Qualcuno del team probabilmente si lamenterà di una particolare porzione dello standard e lo incolperà del fatto che hai utilizzato 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 pregiudizi di codifica quando viene consegnato il codice legacy?
e poi si rendono conto che probabilmente si sarebbero lamentati di qualcosa all'interno dello standard, indipendentemente da dove venisse. Per quanto riguarda il numero di squadre su cui ho lavorato, devo ancora vedere uno standard che a) universalmente è piaciuto eb) concordato con ogni parte dello standard. Fai riferimento ad alcuni dei primi link per vedere come affrontare tali preoccupazioni.

Addendum, hai chiesto di "quale" dovresti usare. In particolare non risponderò a questo dato che ogni risposta è potenzialmente piena di guerre di fiamme alimentate dall'opinione pubblica. Tuttavia, potresti guardare il tuo IDE (Eclipse) e vedere quali opzioni fornisce come configurazione standard. Vorrei anche cercare un po 'e vedere se ci sono progetti che si collegano al tuo IDE e fornire opzioni standard aggiuntive tra cui scegliere. Giusto o sbagliato, quegli standard sono già popolati per te e possono salvare il tuo team un pezzo di lavoro nel configurarlo per tutti.

Vorrei iniziare con Python. Python ha linee guida per la codifica che seguono quasi ogni singolo programmatore python là fuori. Fanno parte della documentazione ufficiale chiamata PEP8 .

C / C ++ è un gran casino per ragioni storiche, ma poiché non lo è python, ti consiglio di seguire la convenzione di denominazione python anche in C / C ++ per motivi di coerenza.

Ora per C ++ è in realtà più importante concordare idiomi comuni e assicurarsi che tutti comprendano uno stile C ++ moderno e ragionevole rispetto a qualsiasi guerra su convenzioni di denominazione. Dovresti iniziare con gli standard di codifica C ++ e dalle risorse online assicurati di leggere le domande frequenti su C ++ .

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

Uno standard di codifica è un insieme di regole che definiscono quali meccanismi linguistici ti è permesso usare, quali non ti è permesso usare e come usarli. In altre parole, si definisce un sottoinsieme della lingua utilizzata e / o un superset, se lo standard di codifica si rivolge a determinate estensioni non standard.

Uno standard di stile di codifica si occupa solo di questioni estetiche: dove posizionare parentesi graffe e spazi, come nominare identificatori, come inserire commenti ecc.

Queste due cose diverse potrebbero trovarsi nello stesso documento. Tuttavia, gli standard di codifica più seri non si occupano di stile - quelli che consiglio di seguito non lo fanno. Molto probabilmente perché lo stile di codifica è molto soggettivo e quindi provoca molto attrito 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 i bug, gli standard MISRA si applicano a qualsiasi ramo di programmazione in cui i bug non sono desiderati.

Gli standard di CERT sono anche abbastanza noti e più orientati alla programmazione desktop e alla sicurezza del software (piuttosto che alla 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'uso di uno standard esistente come base per i propri presenta numerosi vantaggi. Il tuo codice sarà probabilmente più simile al codice esterno, rendendo più semplice la lettura / integrazione del codice. Inoltre, se scegli un buon livello, sarà esaminato da esperti che hanno avuto buone ragioni per decidere le loro regole particolari. Finché nessuno nella tua squadra è particolarmente legato a uno standard, ci sono poche ragioni per non usare uno standard esistente come base per il tuo.

Se non sei sicuro di quali standard di codifica usare, ci sono alcune prime scelte ovvie ideali. In nessun ordine particolare:
1. Qualunque standard sia già supportato dal tuo IDE. Questo è probabilmente configurabile.
2. Qualunque standard sia usato / raccomandato dall'autore del compilatore.
3. Qualunque standard sia utilizzato / raccomandato dall'autore del framework principale (se presente).
4. Qualunque standard sia usato / raccomandato dall'autore / i / progettista / i del proprio linguaggio di programmazione.
5. Qualunque standard sia utilizzato / raccomandato da una società molto grande.

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

Uno standard di solito aiuta la comunicazione e la manutenzione. A mio avviso, dovrebbe essere soggetto ad alcuni dare e avere, soprattutto in piccoli team, e dovrebbe evolversi. Chiamarle 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 dove sono stati utilizzati anche quegli standard, che non è quello che vuoi che accada :)

Gli standard sono lì solo per incoraggiare una più facile collaborazione, quindi se sai che una macro #define è sempre in maiuscolo, quindi quando vedi un identificatore maiuscolo nel codice, avrai una buona idea che sia una macro. Allo stesso modo, altre convenzioni di denominazione o convenzioni di stile ti ricorderanno con cosa hai a che fare.

Trovo che standard come la posizione e il nome del file siano più utili1 di quelli del codice (dopo tutto, il codice ha tutte le forme e dimensioni, e devi ancora leggerlo) mentre non sapendo che readme.txt è in / bin / doc / debug / release / documenti è un vero dolore (come è un percorso così scadente, ma questa è un'altra storia).

Ti consiglierei di fare i tuoi standard mentre vai avanti. In questo modo, non solo ottieni quelli che ti piacciono tutti, ma ottieni quelli che sono sicuramente adatti a te, alla tua squadra e al lavoro che fai. Se decidi che non ti interessa davvero che aspetto abbia un ciclo while o che le dichiarazioni dei casi debbano essere rientrate in un certo modo, allora sei bravo. Se decidi che gli operatori ++ sono esclusi, va bene. Tutta la tua scelta.

Dovresti rendere più facile trovarlo e aggiornarlo, magari una wiki o una pagina web generata automaticamente da una descrizione testuale, ma per il resto - provaci. 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 aiuti dove ne hai bisogno.