So che è stato dimostrato che uno standard di codifica aiuta enormemente. Tuttavia, ci sono molti strumenti e IDE diversi che verranno formattati secondo lo standard preferito dal programmatore. Finché il codice è pulito / commentato (e non un pasticcio di spaghetti), non vedo la necessità di uno standard di codifica.

Ci sono argomenti per lo sviluppo di uno standard di codifica (non ne abbiamo uno, ma stavo cercando di crearne uno)?

Tuttavia, ci sono molti strumenti e IDE diversi che verranno formattati secondo lo standard preferito dal programmatore.

Buona fortuna. La mia esperienza, ci sono un numero minuscolo di strumenti (zero!) Che possono riformattare correttamente il codice dal formato X al formato Y. Ci sono troppe cose che si frappongono. Schede vs spazi, istruzioni multilinea, ecc. Basta guardare l'implementazione di GNU dei file di libreria standard C ++. Quello che puoi fare è far fare il tuo IDE è usare sempre gli spazi invece delle schede e non preoccuparti di riformattare il codice esterno. Ora il tuo codice appare come piace a te e il codice esterno sembra come l'autore originale lo ha scritto.

Uno stile di rientro specifico è l'ultima cosa che uno standard di codifica dovrebbe specificare. Sta per iniziare una guerra religiosa di programmazione. IMO, uno standard di codifica dovrebbe specificare una serie ragionevole di stili di rientro accettabili, ma lasciare i dettagli agli autori di un pacchetto. Lo stile di rientro è, o dovrebbe essere, una piccola parte di uno standard di codifica. Regola numero zero degli standard di codifica: non sudare le piccole cose. Lo stile di rientro è una piccola cosa.

Cose più grandi:

• Come posso nominare le cose?
• Alcune parti della lingua sono vietate?
• Il codice deve essere compilato pulito e con quali impostazioni del compilatore?
• Il codice deve passare determinate metriche?
• Che tipo di test è necessario?
• Che tipo di documentazione è necessaria, sia nel codice (commenti) che altrove?
• Soprattutto, come posso ottenere una deroga allo standard?

Addendum
Forse ancora più importante è ciò che non deve essere inserito negli standard di codifica. Argomenti come come scrivere i requisiti non appartengono agli standard di codifica. Neanche i dettagli sui test. Un progetto non dovrebbe utilizzare gli standard di codifica come supporto per il piano di gestione del progetto, il piano di gestione dei test, il piano di verifica e convalida, ecc. L'obiettivo degli standard di codifica è migliorare la sicurezza del codice, la qualità, la comprensibilità, la manutenibilità, e altre "ilicità". Esistono molti modi per garantire che ciò non accada. Solo alcuni: rendere gli standard un libro complesso come le leggi fiscali di alcuni paesi, incoraggiare la programmazione di guerre di religione, avere cattive convenzioni di denominazione.

Gli standard di codifica possono avere conseguenze non intenzionali. Esempio: Un idiota di un ingegnere di progetto sta per interpretare la "magia regola i numeri" per significare che if (index == 0) {...}e for (ii = 0; ii < 3; ++ii) {...}deve essere modificato in if (ZERO == index) {}e for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}non ridere. L'ho visto accadere. Al giorno d'oggi, quando scrivo uno standard di codifica, è una "linea guida senza numeri magici" piuttosto che una regola per contrastare questo tipo di follia.

Lo standard di codifica non è la difesa numero uno contro il cattivo stile di programmazione / pratiche di codifica pericolose. La revisione del codice è. Nonostante molti anni di automazione, non c'è ancora niente di meglio che avere una serie soggettiva di occhi umani che guardi e giudichi un pezzo di codice.

Gli standard di codifica non riguardano solo i parametri preferiti per indent: includono anche convenzioni di denominazione, convenzioni di commento e un gran numero di possibili raccomandazioni per idiomi, uso delle funzionalità del linguaggio, ecc.

Più precisamente, devi ancora documentare tutto questo da qualche parte. E infine, non tutti vorranno usare un IDE che riformatta il codice in quel modo ...

Se usi uno stile coerente all'interno di una squadra, il tuo codice diventa più facile da leggere. Quando il tuo codice diventa più facile da leggere, il tuo team sarà più produttivo. Saranno più produttivi perché non devono analizzare mentalmente il codice e possono concentrarsi sulla logica piuttosto che sulla sintassi durante la revisione e la manutenzione del codice.

Se ogni persona consente all'IDE di riformattare il codice in base alla propria scelta, si verifica uno dei due problemi seguenti: o è necessario assicurarsi di convertirlo sempre nel formato originale durante il salvataggio o soffrire del fatto che il diff mostrerà molto rumore, rendendo più difficile vedere cosa è cambiato nella logica del codice.

Risposta breve: Sì, riflette la qualità .

Che cos'è e perché ne abbiamo bisogno?

Gli standard di codifica sono pezzi molto importanti di software di alta qualità. Fanno aumentare la produttività nel processo di sviluppo, il codice marca più facile da mantenere, e mantenere il codice di essere legato a una persona o un gruppo. La coerenza nello standard di codifica differenzia anche il codice creato prematuramente dall'arte ben realizzata.

OK, ogni sviluppatore sa che le convenzioni di codifica sono buone. Ma da dove dovrebbero provenire gli standard?

È principalmente dettato dal venditore che possiede il prodotto. Ogni sviluppatore può scegliere tra molti standard di codifica del settore. Alcune aziende Microsoft, Oracle e Sun Microsystems offrono linee guida.

Ci sono argomenti per lo sviluppo di uno standard di codifica (non ne abbiamo uno, ma stavo cercando di crearne uno)?

Sì, ci sono standard di settore che si consiglia di utilizzare. Tuttavia, ogni standard di codifica è specifico per la piattaforma di sviluppo. Pertanto, gli standard di codifica sono principalmente specifici della lingua. Ad esempio, Java ha uno standard diverso da .NET. Ad esempio, C # .NET utilizza tali standard in questo riferimento .

Standard comuni

Gli standard comuni non dipendono da alcun linguaggio di programmazione. Oltre agli standard offerti dal fornitore, ovvero gli standard di codifica del settore citati, esistono diverse notazioni di programmazione come Notazione ungherese o CamelCase . Penso che gli standard di codifica di Microsoft .NET inizialmente si basassero sulle notazioni di CamelCase.

Standard e linee guida per la codifica del team

Pensare che ogni team di sviluppo dovrebbe concordare standard di codifica non appena il progetto viene avviato. Le linee guida per la codifica vengono generalmente create dal Team Lead o dal Chief Architect della società. Di solito è un documento aperto da seguire e migliorare in caso di necessità. Ad esempio, nella nostra azienda abbiamo pagine Wiki in cui questo documento è caricato e disponibile per gli sviluppatori dell'azienda.

Prenderò l'opinione controversa e dirò di no, non è necessario uno standard di codifica . O le regole sono, come dici tu, linee guida esecutive IDE, best practice generali che tutti in ogni azienda dovrebbero seguire, o sono chiamate di giudizio caso per caso che dovrebbero essere fatte da più di una persona in un team capace tramite programmazione in coppia o revisioni del codice.

Cose come Come dovremmo chiamare questa variabile? Quali funzionalità linguistiche dovremmo usare? Dovremmo evitare? Qual è il test migliore? È meglio lasciarli senza risposta fino a quando non incontriamo il problema strettamente definito a cui stiamo lavorando in questo momento .

Cristallizzati da queste minime decisioni, possono sorgere standard / modelli informali all'interno dei team, in base all'intersezione con l'attuale dominio problematico e le tecnologie in uso. Codificare questi significa che pensiamo che cose come lo standard di denominazione, il sottoinsieme linguistico appropriato, ecc. Utilizzati su questi progetti, basati su centinaia di micro decisioni e adottati in modo informale da questi team dovrebbero guidare ogni progetto a progredire.

In linea di principio sembra una cosa grandiosa, ma in realtà diventa solo una calamita per la politica. Quali strumenti possiamo costringere tutti a usare? Cosa voglio costringere altre persone a evitare? Se tutti fossero d'accordo su queste domande, non avremmo bisogno di uno standard. Lo faremmo e basta. Nella mia esperienza, gli standard nascono dal desiderio che un sottoinsieme degli sviluppatori eserciti il ​​controllo su un altro sottoinsieme. In genere questo tipo di politica e la politica di polizia che ne segue soffocano solo l'innovazione anziché fornire una guida.

Se vuoi una vera guida , invece di leggere uno standard con un sacco di regole inutili, vai a trovare membri capaci della tua squadra e chiedi loro cosa ne pensano. Da cosa sono stati bruciati? Come ti suggeriscono di scrivere il codice? Riceverai una varietà di risposte utili con molta esperienza preziosa per il backup. Vedrai molte intersezioni basate sull'esperienza comune. Invece della monocoltura applicata dallo standard, vedrai anche molta diversità che può solo aiutarti a vedere molti modi validi per risolvere i problemi.

E quando qualcuno ti dice di non fare qualcosa causa di una regola nello "standard" ma non ha esperienza o backup ragionevole per la sua affermazione, ignorali. Qui lo standard non è servito a nessuno o ha reso nessuno uno sviluppatore migliore.

Ora che gli aerei commerciali sono fly-by-wire, si spera che i programmi che pilotano l'aereo in base agli input dei piloti funzionino. Quando i programmatori scrivono tale codice, speri che seguano un rigido insieme di regole per evitare errori di programmazione comunemente evitabili. Un modo per farlo è con uno standard di codifica.

Vedi: Standard di codifica C e C ++ proposti dalla Federal Aviation Administration

Devo aggiungere altro.

Nota: non sono riuscito a trovare lo standard attuale dalla FAA online, ma l'ho visto.

Per me è una questione di disciplina ed essere disciplinati aiuta sempre, è un riflesso della qualità del lavoro che produci.

Detto questo, renderei lo standard di codifica tenendo in considerazione l'IDE e / o gli strumenti in uso. Inoltre, l'IDE dovrebbe essere configurato in modo identico (ad esempio, l'IDE di ogni sviluppatore dovrebbe utilizzare tutte le schede o tutti gli spazi bianchi per il rientro e l'IDE di tutti dovrebbe avere la stessa lunghezza di scheda) per ogni sviluppatore in modo che tutti possano seguire facilmente lo standard ...

Inoltre, è possibile sviluppare e utilizzare script per il check-in che possono aiutare ad aderire agli standard di codifica in una certa misura, ad esempio possono correggere il rientro prima di eseguire effettivamente il commit del file archiviato nel sistema di controllo della versione.

Gli standard di codifica NON potrebbero essere più importanti! Sono un appassionato utente di CakePHP e mi piace rivedere i changeset da versione a versione e gli sviluppatori non seguono gli standard lì.

In effetti, ero così sconvolto dalle differenze di stile che dovetti scrivere A Short Rant About Coding Conventions . Costa molto tempo e denaro per portare già nuovi sviluppatori in un team esistente - immagina solo di attirare un nuovo sviluppatore senza standard ... apprendere il codice sarebbe il prossimo troppo impossibile.