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 che preferisce il programmatore. Finché il codice è pulito / commentato (e non è un casino 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)?
However, there are many different tools and IDEs that will format to whatever standard the programmer prefers.
Buona fortuna con quello. La mia esperienza, ci sono un piccolo numero di strumenti (zero!) Che possono riformattare correttamente il codice dal formato X al formato Y. Ci sono troppe cose che si intromettono. Schede e spazi, istruzioni multilinea, ecc. Basta dare un'occhiata all'implementazione di GNU dei file di libreria standard C ++. Quello che puoi fare è fare in modo che il tuo IDE faccia sempre spazi e non tabulazioni e non preoccuparti di riformattare codice estraneo. Ora il tuo codice ha l'aspetto che preferisci e il codice estraneo è simile al modo in cui l'autore originale lo ha scritto.
Uno stile di indentazione specifico è l'ultima cosa che uno standard di codifica dovrebbe specificare. È quasi impossibile iniziare una guerra religiosa di programmazione. IMO, uno standard di codifica dovrebbe specificare una serie ragionevole di stili di indentazione accettabili, ma lasciare le specifiche agli autori di un pacchetto. Lo stile di indentazione è, o dovrebbe essere, una piccola parte di uno standard di codifica. Regola numero zero degli standard di codifica: non preoccuparti delle piccole cose. Lo stile di indentazione è una cosa piccola.
Cose più grandi:
Addendum
Forse ancora più importante è ciò che non inserire in uno standard di codifica. Argomenti come la scrittura dei requisiti non appartengono agli standard di codifica. I dettagli sul test non appartengono, neanche. Un progetto non dovrebbe utilizzare gli standard di codifica come standard 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 "ilità". Ci sono molti modi per garantire che ciò non accada. Solo alcuni: rendere gli standard un libro complesso come le leggi fiscali di alcuni paesi, incitando alla programmazione di guerre religiose, con cattive convenzioni sui nomi.
Gli standard di codifica possono avere conseguenze indesiderate. Esempio: un pazzo di un ingegnere di progetto interpreterà la "regola dei numeri magici" per indicare che if (index == 0) {...} e for (ii = 0; ii < 3; ++ii) {...} devono essere modificati in if (ZERO == index) {} e for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...} Non ridere. L'ho visto accadere. Oggigiorno, quando scrivo uno standard di codifica, è una "non guida ai 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 recensione del codice è. Nonostante molti anni di automazione, non c'è ancora niente di meglio che avere un insieme di occhi umani in qualche modo soggettivi e giudicare 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 raccomandazioni possibili per l'uso di espressioni idiomatiche, linguaggio, ecc.
Più precisamente, devi comunque documentare tutto da qualche parte. Infine, non tutti vorranno utilizzare un IDE che riformatta il codice in questo modo ...
Se si utilizza uno stile coerente all'interno di un team, il 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 lascia l'IDE riformattare il codice a sua scelta, si ha uno dei due problemi: o è necessario assicurarsi di convertirlo sempre nel formato originale al momento del salvataggio, o soffrire del fatto che il tuo diff mostrerà molto di rumore, rendendo più difficile vedere cosa è cambiato nella logica del codice.
Risposta breve: Sì, riflette la qualità .
Gli standard di codifica sono una parte molto importante del software di alta qualità. Eseguono aumentare la produttività nel processo di sviluppo, semplificano la manutenzione del codice e impediscono che il codice venga associato a una sola persona o team. La coerenza nello standard di codifica differenzia anche il codice creato prematuramente dall'arte ben fatta.
OK,everydeveloperknowsthatcodingconventionsaregood.Butwhereshouldstandardscomefrom?
Èprincipalmentedettatodalvenditorechepossiedeilprodotto.Ognisviluppatorepuòsceglieretramoltistandarddicodificadelsettore.AlcuneaziendeMicrosoft,OracleeSunMicrosystemsoffronolineeguida.
Arethereanyargumentsforthedevelopmentofacodingstandard(wedon'thaveone,butIwaslookingintocreatingone)?
Sì,cisonostandarddisettorechesiconsigliadiutilizzare.Tuttavia,ognistandarddicodificaèspecificoperlapiattaformadisviluppo.Pertanto,glistandarddicodificasonoperlopiùspecificidellinguaggio.Adesempio,Javahaunostandarddiversoda.NET.Adesempio
Gli standard comuni non hanno dipendenze da alcun linguaggio di programmazione. Oltre agli standard offerti dal fornitore, noti anche come standard di codifica del settore, esistono diverse notazioni di programmazione come Notazione ungherese o CamelCase . Penso che gli standard di codifica di Microsoft .NET fossero inizialmente basati sulle notazioni CamelCase.
Nel pensare, ogni team di sviluppo dovrebbe accordarsi sugli standard di codifica non appena viene avviato il progetto. Le linee guida per la codifica sono solitamente create dal Team Lead o dal Chief Architect dell'azienda. Di solito è un documento aperto da seguire e migliorare su una necessità. Ad esempio, nella nostra azienda abbiamo pagine Wiki in cui questo documento è caricato e disponibile per gli sviluppatori della società.
Prenderò l'opinione controversa e dirò no non hai bisogno di uno standard di codifica . O le regole sono, come dici tu, le linee guida attuabili IDE, le migliori pratiche generali che tutti dovrebbero seguire in ogni azienda, o sono le chiamate al giudizio caso per caso che dovrebbero essere fatte da più di una persona su una squadra capace tramite coppie di programmazione o recensioni di codice.
Cose come Come dovremmo nominare questa variabile? Quali caratteristiche linguistiche dovremmo usare? Dovremmo evitare? Quale test è il migliore? È meglio lasciarli senza risposta finché non incontriamo il problema strettamente definito su cui stiamo lavorando in questo momento .
Cristallizzato da queste minuziose decisioni, possono sorgere standard / schemi informali all'interno dei team, basati sull'intersezione con il dominio problematico corrente e le tecnologie in uso. Codificando questi mezzi pensiamo che cose come lo standard di denominazione, il sottoinsieme di lingue appropriato, ecc. Usate su questi progetti, basate su centinaia di micro decisioni e adottate in modo informale da questi team, dovrebbero guidare ogni progetto in futuro.
In linea di massima sembra una cosa grandiosa, ma in realtà diventa una calamita per la politica. Quali strumenti possiamo costringere tutti a usare? Cosa voglio forzare ad evitare le altre persone? Se tutti sono d'accordo su queste domande, non avremmo bisogno di uno standard. Lo faremmo e basta. Nella mia esperienza, gli standard derivano dal desiderio che un solo sottoinsieme degli sviluppatori eserciti il controllo su un altro sottoinsieme. In genere questo tipo di politica e la polizia tecnologica che ne consegue soffoca solo l'innovazione piuttosto che fornire indicazioni.
Se vuoi guida reale , invece di leggere uno standard con una serie di regole inutili, trova i membri capaci del tuo team e chiedi loro cosa ne pensano. Di cosa sono stati bruciati? Come ti suggeriscono di scrivere il codice? Avrai una varietà di risposte utili con un sacco di preziosa esperienza per il backup. Vedrai molte intersezioni basate su un'esperienza comune. Invece della monocultura imposta dallo standard, vedrai anche molte diversità che possono 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 della loro richiesta, ignorali. Qui lo standard non ha servito nessuno o ha reso nessuno uno sviluppatore migliore.
Ora che gli aerei commerciali sono volanti, speriamo che i programmi che pilotano l'aereo in base all'entrata dei piloti funzionino. Quando i programmatori scrivono questo 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: Proposta Federal Aviation Administration C e C ++ Standard di codifica
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 e l'essere sempre disciplinato aiuta sempre, è un riflesso della qualità del lavoro che produci.
Detto questo, vorrei rendere 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 della tabulazione) per ogni sviluppatore in modo che tutti possano seguire facilmente lo standard ...
Inoltre, potrebbero essere sviluppati e utilizzati script di check-in che potrebbero aiutare ad aderire agli standard di codifica in una certa misura, ad es. possono correggere il rientro prima di inviare effettivamente il file archiviato nel sistema di controllo della versione.
Gli standard di codifica NON potrebbero essere più importanti! Sono un avido utente di CakePHP e mi piace rivedere i changeset dalla versione alla versione e gli sviluppatori non seguono gli standard lì.
In effetti, ero così sconvolto dalle differenze di stile che dovevo scrivere A Short Rant Informazioni sulle convenzioni di codifica . Costa un sacco di tempo e denaro a portare già nuovi sviluppatori in un team già esistente - immagina di portare un nuovo sviluppatore senza standard ... l'apprendimento del codice sarebbe presto impossibile.
Leggi altre domande sui tag coding-standards ide