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

Recentemente ho visto che Microsoft ha rilasciato un documento sugli standard di codifica ( All-In-One Code Framework Coding Standards ) e mi ha fatto pensare ... La società per cui lavoro non ha affatto standard di codifica formali. Ci sono solo pochi sviluppatori e siamo stati insieme abbastanza a lungo per esserci evoluti in stili simili e non è mai stato un problema.

L'azienda per cui lavori ha standard di codifica documentati? Se no, perché no? Avere uno standard fa la differenza? Vale la pena scrivere uno standard da zero o dovresti adottare un altro standard come tuo (cioè rendere gli standard di Microsoft tuoi)?

È importante che un team abbia un unico standard di codifica per ogni lingua per evitare diversi problemi:

• La mancanza di standard può rendere illeggibile il tuo codice.
• 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 lo zio Bob ha da dire sugli standard:

1. Lasciateli evolvere durante le prime iterazioni.
2. Lascia che siano specifici del team anziché specifici dell'azienda.
3. Non scriverli se puoi evitarlo. Piuttosto, lascia che il codice sia il modo in cui vengono catturati gli standard.
4. Non legiferare sul buon design. (es. non dire alle persone di non usare goto)
5. Assicurati che tutti sappiano che lo standard riguarda la comunicazione e nient'altro.
6. Dopo le prime iterazioni, riunisci la squadra per decidere.

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

• Rende molto più semplice la lettura di tutta la base di codici, poiché è fastidioso passare da uno stile di codifica all'altro.
• Rende più semplice la lettura di un singolo file, dal momento che qualsiasi file aggiornato da due sviluppatori con stili in conflitto tenderà alla fine a mescolarli. Leggere un file che mescola schede e spazi (e modificarlo in seguito) è una seccatura.
• Rende più facile per i nuovi sviluppatori usare un buon stile se esiste uno standard esplicito, piuttosto che implicito.
• Convenzioni di denominazione coerenti rendono molto più facile trovare funzioni / variabili. Era ArraySort o array_Sort o sortTheArray o doSortArray o ...?

In termini di adozione di uno standard esistente, non importa davvero: la coerenza è ciò che è importante. Se i tuoi sviluppatori hanno una dozzina di stili diversi, potresti anche sceglierne uno esistente e pubblicato. Se ti sei evoluto tutti in uno stile abbastanza coerente, scrivilo e usalo.

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

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

Non sopporto davvero quando i programmatori C scrivono codice Java con formattazione C. Non solo non sembra 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

Il mio ex datore di lavoro ha uno standard di codifica. Sto pensando di documentarne formalmente anche uno per me.

Oppure, come suggerisci, trovare uno standard decente esistente e modificarlo / adottarlo. Per un'azienda, suggerirei sicuramente che guardano agli standard di codifica esistenti, ma ne creano / modificano uno per le proprie esigenze particolari. Non è necessario crearne uno da zero, ma è necessario fare attenzione a garantire che lo standard di codifica abbia senso per il tipo di software creato dalla società.

Sì, avere uno standard di codifica fa la differenza, ma non è un proiettile d'argento. Il codice è più leggibile in quanto non ci sono molti tipi diversi di scontro e alcuni errori / insidie ​​comuni possono essere evitati. Anche con uno standard avrai alcune variazioni negli stili di codifica, ma tale variabilità sarà ridotta. L'obiettivo non è cercare di evitare tutte le variazioni o prepararsi per ogni possibile situazione. Uno standard di codifica troppo complicato può essere peggio di niente.

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

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

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

Tenere presente che si tratta di un documento sugli standard di codifica specifico per il Framework del codice All-In-One.

Ho lavorato in varie aziende, alcune delle quali avevano uno standard esistente e alcune (la maggior parte) delle quali ho contribuito a sviluppare lo standard. Per la maggior parte, se si sta eseguendo uno sviluppo basato su .NET (e anche se non lo è, la maggior parte delle regole si applica ancora) è necessario dare un'occhiata alle Linee guida per la progettazione del framework . Sebbene ciò sia specifico per la scrittura di API rivolte al pubblico, la maggior parte delle linee guida si applica ugualmente bene a qualsiasi codice.

La più grande preoccupazione per gli standard di codice è di mantenerlo relativamente semplice e diretto. Volete che gli sviluppatori siano in grado di interiorizzare le linee guida presentate, quindi fornire loro un documento di oltre 50 pagine è inutile. Puoi comunque creare quel documento se vuoi fornire uno sfondo, esempi, ecc. Ma vorrai anche qualcosa che si riduce a una serie di linee guida. Il tuo standard di codifica deve anche essere un documento flessibile e vivente che deve cambiare al variare della tecnologia.

Le discussioni sulla codifica standard si riducono a questo:

• Sì, ne hai bisogno, la coerenza e il codice pulito sono una pietra miliare del buon sviluppo.
• Quello che sono quasi non importa, purché tutti seguano gli stessi standard.
• Non scrivere il tuo, sei finito in una discussione infinita e dolorosa. Ci sono molti là fuori che sono popolari.
• L'uso di standard pubblici (come quelli su MSDN ) ti offre una terza parte agnostica di cui non puoi discutere. Se vuoi discutere con loro, fai riferimento al punto 2.

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

Siamo un negozio blub, quindi usiamo le convenzioni di programmazione blub.

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

In effetti, grazie al design di blub, qualsiasi programmatore blub può leggere qualsiasi singolo file blub e capirlo, perché blub non ha un sistema macro.

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

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

Può aiutare le persone, può anche davvero aiutare con gli strumenti:

Se vuoi essere in grado di utilizzare qualsiasi tipo di formattazione automatica del codice di cui hai davvero bisogno per standardizzare le regole che utilizzerà, altrimenti otterrai costantemente molte modifiche di formattazione insignificanti che ingombrano le tue differenze.

I set di regole predefiniti per gli strumenti di analisi statica possono verificare uno stile di denominazione specifico ed è probabilmente più semplice conformarsi a quello, quindi scrivere un sacco di nuove regole. (a meno che non disattivi completamente la regola)

infine, è bene standardizzare tutto ciò che deve essere consultato con qualcuno al di fuori del proprio team. vale a dire che probabilmente desideri un avviso sul copyright standard nelle intestazioni poiché 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 la prima volta