La tua azienda ha uno standard di codifica? [chiuso]

È importante per una squadra avere un unico standard di codifica per ogni lingua per evitare diversi problemi:

• Una mancanza di standard può rendere il tuo codice illeggibile.
• Il disaccordo sugli standard può causare guerre di check-in tra gli sviluppatori.
• Vedere standard diversi nella stessa classe può essere estremamente irritante.

Sono un grande fan di ciò che Uncle Bob ha da dire sugli standard:

1. Let them evolve during the first few iterations.
2. Let them be team specific instead of company specific.
3. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured.
4. Don't legislate good design. (e.g. don't tell people not to use goto)
5. Make sure everyone knows that the standard is about communication, and nothing else.
6. After the first few iterations, get the team together to decide.

Penso sia essenziale avere uno standard di codifica, anche se tutto ciò che dice è "usiamo il rientro a 3 spazi e le parentesi aperte vanno nella riga successiva". Alcuni vantaggi:

• Rende molto più semplice la lettura dell'intero code-base, poiché passare da uno stile di codifica all'altro è fastidioso.
• Rende la lettura di un singolo file più semplice, poiché qualsiasi file aggiornato da due sviluppatori con stili in conflitto finirà per indurre a mescolare questi stili. Leggere un file che mischia tab e spazi (e modificarlo in seguito) è un rompicapo.
• È più facile per i nuovi sviluppatori utilizzare un buon stile se esiste uno standard esplicito, piuttosto che uno implicito.
• Le convenzioni di denominazione costanti rendono molto più facile trovare funzioni / variabili. Era ArraySort o array_Sort o sortTheArray o doSortArray o ...?

Per quanto riguarda l'adozione o meno di uno standard esistente, non importa - la coerenza è ciò che è importante. Se i tuoi sviluppatori hanno una dozzina di stili diversi, puoi anche scegliere uno esistente, pubblicato. Se ti sei evoluto in uno stile abbastanza coerente, scrivilo e usalo.

Non sono d'accordo con "siamo un negozio X", quindi formiamo il nostro codice in tutte le lingue allo stesso modo.

Personalmente ho scoperto che la maggior parte delle lingue ha diversi stili accettati.

Non riesco davvero a sopportare quando i programmatori C scrivono il codice Java con la formattazione C. Non solo non assomiglia a Java, ma li induce a pensare di poter usare altre pratiche simili a C in Java.

Penso che se hai uno standard dovrebbe essere per lingua

Purtroppo no. Quindi ognuno ha il suo modo di usare spaziatura, indentazione e così via, tutto mescolato (in questo modo non è nemmeno necessario utilizzare la funzione "colpa" per sapere chi è l'autore di una riga di codice!)

Ma, peggio ancora, qualcuno scrive nomi di classi e variabili in italiano, qualcun altro in inglese ...

Adattamento sempre il mio stile a quello del linguaggio, della libreria e del framework che sto usando, in modo che un codice sorgente appaia uniforme e chiaro.

Tieni presente che si tratta di un documento standard di codifica che è specifico per il framework di codici multifunzione.

Ho lavorato in diverse aziende, alcune delle quali avevano uno standard esistente e alcune (la maggior parte) delle quali ho aiutato a sviluppare lo standard. Per la maggior parte, se stai facendo lo sviluppo basato su .NET (e anche se non lo sei, la maggior parte delle regole si applicano ancora) dovresti dare un'occhiata a Linee guida per la progettazione di framework . Sebbene questo sia specifico per la scrittura di API pubbliche, la maggior parte delle linee guida si applica ugualmente bene a qualsiasi codice.

La più grande preoccupazione per gli standard di codice è di mantenerla relativamente semplice e diretta. Vuoi che gli sviluppatori siano in grado di interiorizzare le linee guida presentate, quindi è inutile dare loro un documento di oltre 50 pagine. È ancora possibile creare quel documento se si desidera fornire sfondo, esempi, ecc., Ma si vorrà anche qualcosa che si riduce ad una serie di linee guida bullettate. Il tuo standard di codifica deve anche essere un documento flessibile e vivente che deve essere modificato al cambiare della tecnologia.

Le discussioni sulla codifica standard si riducono a questo:

• Sì, ne hai bisogno, coerenza e codice pulito sono una pietra miliare del buon sviluppo.
• Quello che sono quasi non ha importanza, a patto che tutti seguano gli stessi standard.
• Non scrivere il tuo, sei finito in una discussione infinita e dolorosa. Ci sono molte cose che sono popolari.
• L'uso di standard pubblici (come quelli su MSDN ) ti offre una terza parte agnostica che può essere discusso con. Se vuoi discutere con loro, fai riferimento al punto 2.

Se stai sviluppando in C # in Visual Studio, allora StyleCop è un proiettile d'argento. Se utilizzi anche ReSharper, il StyleCop per ReSharper è semplicemente fantastico.

Siamo un blub shop, quindi utilizziamo le convenzioni blub di programmazione.

Ora Paul Graham e gli amici sono molto più intelligenti di noi, ma noi programmatori blub, tutti possiamo leggere l'un l'altro blub, infatti, qualsiasi programmatore blub può leggere il nostro blub code.

Infatti, a causa del design di blub, ogni programmatore blub può leggere qualsiasi singolo file blub e capirlo, perché blub non ha un sistema macro.

Se programmiamo, ad esempio, C o C ++ (siamo tutti multilingue, anche se programmiamo in blub) usiamo principalmente lo stile blub per il nuovo codice, o per le cose open source, lo standard del progetto che stiamo lavorando a.

Hai bisogno di uno standard. Ho visto standard diversi in diversi angoli di un'applicazione con diversi lead che tutti volevano farlo "a modo loro". Forse il concetto di "standard" è stato frainteso. Molto pazzo. E i peggiori standard sono generati da una sola persona. Non importa chi sia quella persona, se solo una persona sviluppa lo standard, è quasi certo che sia una cattiva.

Può aiutare le persone, può anche essere di grande aiuto con gli strumenti:

Se vuoi essere in grado di usare qualsiasi tipo di formattazione automatica del codice hai davvero bisogno di standardizzare le regole che userai, altrimenti riceverai costantemente molte modifiche di formattazione insignificanti che ingombrano le tue diff.

I set di regole predefinite per gli strumenti di analisi statica potrebbero verificare uno stile di denominazione specifico, ed è probabilmente più facile a tutto tondo conformarsi a questo, quindi scrivere una serie di nuove regole. (a meno che non stia per disattivare completamente la regola)

infine è bene standardizzare tutto ciò che deve essere consultato con qualcuno al di fuori del tuo team. ad esempio, è probabile che tu voglia un avviso di copyright standard nelle intestazioni in quanto non vuoi eseguire tutti i nuovi file che scrivi oltre il team legale della tua azienda e sicuramente desideri ottenere i nomi di qualsiasi API pubblica correttamente la prima volta