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.