Mi è stato chiesto di documentare gli standard di codifica per javascript a livello della mia organizzazione. Il mantenimento degli standard di codifica a livello della mia organizzazione suona abbastanza valido? tipo di vecchi temporizzatori? a proposito, come javascript si evolve con framework come AngularJS, dovremmo semplicemente riferirci allo standard del settore invece di mantenerli nell'organizzazione? Li vedo diventare obsoleti abbastanza spesso.
Gli standard di codifica hanno generalmente due obiettivi
Cercano di impostare una guida di stile comune per il codice.
Avere uno stile comune rende più facile per le persone comprendere la base di codice nel suo insieme, perché non vengono distratti da banalità come le modifiche nel posizionamento di indentazione o di parentesi graffa.
È fondamentale che uno stile comune venga utilizzato all'interno di un team, ma se scambi spesso codice e / o persone tra team, allora una guida di stile comune per l'azienda nel suo insieme può essere vantaggiosa.
Guidano le persone in costrutti linguistici che dovrebbero essere evitati perché sono noti per causare un'alta incidenza di bug.
In uno standard di codifica per JavaScript, posso facilmente vedere il divieto di utilizzare == per i confronti di uguaglianza. La parte più importante qui è la spiegazione perché il divieto esiste.
Oltre ad avere uno standard di codifica, devi anche pensare a come applicare le regole in quello standard di codifica. La strong preferenza qui è quella di avere strumenti in grado di far rispettare automaticamente le regole.
Alcune osservazioni e le mie conclusioni:
Diversi stili di approccio JS Mentre una squadra potrebbe lavorare su una nuova versione di Angular Typescript Stuff, un altro team potrebbe avere un software più vecchio da mantenere. E c'è anche la cultura della squadra. Non ci sarà solo uno standard per tutti. Le persone guarderanno anche in altre lingue e adatteranno i modelli da lì. Quindi non c'è bisogno di uno standard
È necessario applicare uno standard Quindi, se tutti voi volete avere degli standard o vi siete resi conto che un mucchio di pseudo-standard, a cui nessuno realmente aderisce, non stanno aiutando. Abbassati e parla (scegli un gruppo di sviluppatori interessati) perché e come vedi gli standard. Inchiodarli In un file .jshint. Non eseguire il commit del codice che genera errori di suggerimento. Un commit è un mucchio di righe di modifiche al codice e non c'è davvero nulla da controllare. Abituati a non sh ** più nel tuo CVS / SVN / GIT più. Avrei optato per regole meno rigide nei reposli brutti e un set più chiaro di un po 'di più negli altri. Lascia spazio per l'interpretazione: schede o spazi? Non preoccuparti nemmeno. Tutti si assicurano che sia o meno Tabs AND Spaces.
Ogni team / repository può avere un proprio standard C'è una componente sociale in questo. Gli standard si evolveranno e gli sviluppatori con competenze crescenti tendono ad avere un numero limitato di rigidi relativi. Offri ai team, forse un forum, un po 'di leva e spazio per scambiare idee e le cose migliorano. Se sei responsabile di tale iniziativa, trova i modi per monitorare il successo delle squadre che aderiscono agli standard (codice clima ecc.). Fondamentalmente ogni repository dovrebbe dare una semplice intuizione di quanto sia pulito, in base alle regole imposte dall'utente.
TL;TR: Let Teams/Projects define standards, give them the tools to enforce them and help keeping the code structured as everyone on the team expects. Some reasoning with own company culture, tech and approach helps here finding sensible defaults.
Nel corso del tempo, sono giunto alla conclusione che il motivo principale per cui uno standard di codifica è quello di ridurre al minimo le differenze banali durante la revisione / fusione dei file nel sistema scm.
Penso solo per questo motivo, uno standard basato su stile / formato è valsa la pena.
Raccomando vivamente di utilizzare un comune (tutti i membri del team usano lo stesso strumento e versione e configurare) lo strumento di formattazione sorgente per applicare (in misura ragionevole) questi standard.
Uno standard di codifica delle migliori pratiche è un aspetto più teso. Le pratiche cambiano, e quello che una volta era a posto può cadere in disgrazia. Cosa poi? Hai un sacco di codice non conforme. Mi piacerebbe calpestare qui e lasciare gli standard alle esigenze specifiche dell'organizzazione (ad esempio, non posso usare una libreria di terze parti se non approvata dall'architetto per X).
Leggi altre domande sui tag coding-standards