Ci sono alcune opzioni.
Molti sistemi di controllo delle versioni offrono la possibilità di eseguire script su un commit. Git, dal momento che lo menzioni specificamente, ha hook pre-commit . Ma non è univoco per Git - Subversion ha gli hook pre e post , come fa Mercurial , e anche ClearCase ha un certo livello di abilità di scripting. È possibile utilizzare questi per chiamare automaticamente un formattatore di codice. Ognuno può configurare il proprio IDE (e persino scegliere di riformattare il codice al momento del pagamento) a proprio piacimento, ma l'hook e lo strumento si riformatteranno prima di controllarlo in modo che la versione nel repository corrisponda allo stile di codifica.
Se la tua lingua non ha un buon autoformatter, potrebbe avere un linter che supporta le regole di stile. In tal caso, gli sviluppatori potrebbero aver bisogno di rinunciare alle loro convenzioni di stile personalizzate e adottare le linee guida del team per conto proprio, prima di un commit. Utilizzando i ganci di commit o un server CI, è possibile bloccare le unioni su un ramo principale che non soddisfa le linee guida sulla qualità. Puoi agganciare i linters, gli strumenti di analisi statici e i tuoi test unitari e richiedere che tutto sia accettabile o rischi che una build sia contrassegnata come non riuscita.
Se i tuoi sviluppatori utilizzano IDE, spesso gli strumenti di formattazione sono incorporati. Se uno sviluppatore crea uno stile, può essere solitamente esportato e condiviso tra altri sviluppatori che utilizzano lo stesso IDE. Se lo sviluppatore utilizza un editor di testo incentrato sulla programmazione, potrebbero esserci modi per eseguire l'autoformattazione o l'hook in strumenti di autoformattazione. Se ci sono file di configurazione per i tuoi strumenti, puoi esportarli e controllarli in controllo di versione (separati dal tuo progetto) e che servirebbero anche come una versione catturata della tua guida di stile, permettendoti di assicurarti che sia pronto -date.