Le guide di stile del codice aumentano la produttività? [duplicare]

10

Il nostro team di 12 sta attualmente valutando l'implementazione di una guida di stile. La domanda è venuta se i vantaggi della produttività a lungo termine superano la perdita di produttività a breve termine, come tutti si adattano.

Qual è stata la tua esperienza con le guide di stile?

Dovrei anche notare che la nostra base di codice è piuttosto grande e probabilmente dovremo eseguire il nostro codice attraverso la procedura non crittografata o qualcosa di simile per portare l'intera base di codice in conformità con la guida.

    
posta Lance 15.01.2014 - 21:23
fonte

3 risposte

6

La mia esperienza è stata positiva, se il documento di stile è ben progettato.

Mi aspetto di non dover pensare a nessun spazio bianco o regole di indentazione quando scrivo codice, ed essere in grado di usare solo un modello di autoformatura standard. Apprezzo la coerenza quando leggo il codice.

Più importanti della consistenza dello spazio bianco sono i soliti stili / disegni / stili degli spazi dei nomi. Sapere dove puoi cercare qualcosa, e avere una buona possibilità di trovarlo - o essere ragionevolmente sicuro che non esista se non è dove ti aspetti che sia un enorme risparmio di tempo quando stai esplorando una base di codice estesa.

    
risposta data 15.01.2014 - 22:18
fonte
3

Sì e no .. dipende dagli standard. Nota che sento che le guide di stile sono inutili, a chi importa davvero quanti spazi devi mettere tra un operatore e una variabile, o come indentare i tuoi membri.

Tuttavia, una volta che si presume che i programmatori conoscano la propria roba, sono abbastanza professionali da mantenere la coerenza all'interno di un file di codice (cioè non riformatterà tutto solo a causa di una preferenza personale) e qualsiasi guida che si presenterà non sarà mai perfetta, puoi iniziare a crearti qualcosa di veramente utile.

Gli standard contribuiscono maggiormente quando riguardano la comunicazione. Sono al loro peggio quando si tratta di restrizioni.

Quindi una guida che spiega come posizionare il progetto, dove trovare il file di progetto principale (.sln o makefile o whatnot), dove si trova il punto di ingresso e come nominare i file in modo che qualcuno che arriva possa scegliere un progetto mai visto prima e sapere esattamente dove cercare le cose che devono trovare ... vale la pena il suo peso in oro.

Avevo un documento standard che diceva che hai praticamente progettato un progetto in un certo modo: il .sln era incluso nella directory (cioè non c'era nessuno di questo file di progetto e una sottodirectory di codice), che lì era sempre una directory di rilascio contenente tutto il necessario per consegnare il componente, che ogni directory di rilascio conteneva un file readme.txt che conteneva un riepilogo del componente, quali elementi speciali dovevi fare per crearlo e cosa dovevi fare per distribuire esso. Quando tutti lo sapevano, non avresti mai avuto bisogno di dirglielo: potevo semplicemente dirigere un ingegnere di sistemi presso il repository di origine e sarebbero in grado di distribuirlo da soli, senza bisogno di maniglie e tutto a causa della coerenza con ogni progetto. Potrei dirigere un altro dev al progetto e sarebbero subito operativi perché sapevano come montare il componente nel sistema e costruirlo, e dove erano i bit di codice che dovevano guardare (a causa del ragionevole convenzione di denominazione generica)

Sono sicuro che hai scelto un progetto open source e non sei riuscito a sapere da dove iniziare, con i file di codice sparsi in tutto il negozio, un readme che non ti dice nulla di utile e nessun modo per trovare dove l'output è costruito per, o come usarlo una volta costruito.

Ma in nessun momento ho parlato con i miei amici sviluppatori e dico loro come scrivere il loro codice, o come dovrebbe o non dovrebbe essere il loro codice. La produttività era alta e siamo rimasti tutti contenti della situazione.

Se vuoi davvero una guida di stile e devi comunque eseguire il tuo codice esistente tramite un beautifier ... beh, potresti anche semplicemente eseguire il codice attraverso l'abbellitore prima di ogni check-in e lasciare che tutti codifichino lo stile che preferiscono.

    
risposta data 15.01.2014 - 22:31
fonte
2

Indipendentemente dal fatto che le guide di stile valgano il dolore, dovresti considerare come applicheresti la norma in quanto ciò rappresenterebbe un maggiore ostacolo alla produttività rispetto all'apprendimento della guida.

Come sviluppatore C #, sono un sostenitore dell'adozione di StyleCop come strumento di conformità e utilizzo delle sue regole come guida. È uno strumento di analisi statico che posso eseguire dall'IDE che analizzerà il codice sorgente a livello di documento / progetto e di elencare tutte le violazioni come avvertenze. Questo non mi impedisce di costruire, e non ho bisogno di imparare le regole in anticipo.

    
risposta data 15.01.2014 - 22:00
fonte

Leggi altre domande sui tag