Gli standard di codifica devono essere applicati dal server di integrazione continua?

Gli standard di codifica dovrebbero essere lì per un motivo ... e le non conformità dovrebbero essere controllate.

Tuttavia, non tutte le violazioni dovrebbero essere considerate come errori - così come non tutte le violazioni di compilazione sono. Dove si disegna la linea deve essere una decisione aziendale e di uno strumento.

Ad esempio, MISRA definisce le sue regole come Richiesto e Advisory ... Suggerirei che gli advisor avrebbero permesso alla build di procedere.

Non è del tutto sconosciuto e saprai se funzionerà solo per te provandolo. Ci sono alcuni passaggi che potresti essere preso prima.

Prima la squadra dovrebbe decidere insieme gli standard. Quindi strumenti come ReSharper dovrebbero essere usati per dire agli sviluppatori se non aderiscono agli standard. Fare delle recensioni tra pari su ogni attività potrebbe essere di ulteriore aiuto.

Dopo che sono stati presi questi passaggi, si potrebbe considerare di mettere controlli standard di codifica a CI-server. Tuttavia dovrebbe essere ancora considerato se è saggio avere un'interruzione di costruzione per non aderire agli standard di codifica. Il rischio è che avrai molte build rotte che potrebbero dillutare il significato di build fallita.

Invece di interrompere la compilazione, è possibile eseguire gli strumenti e creare report. Se la codifica delle violazioni standard sembra aumentare, puoi riunire la squadra e capire perché sta accadendo.

Should coding standards/style be enforced by the continuous integration server running static analysis tools (ex. PMD, StyleCop/FxCop) and failing the build if the standards are not followed?

Quei controlli di integrazione continui devono essere molto, molto veloci. Eventuali ritardi significativi faranno sì che i tuoi programmatori commettano e perdano traccia del loro processo di pensiero mentre aspettano i risultati. Rendilo più lungo e si impegneranno a prendere un caffè o a chiacchierare con i loro compagni di ufficio sulle ultime prestazioni pasticciate di qualche squadra sportiva. Questi ritardi sono altamente controproducenti. È meglio lasciare alcune cose alla compilazione notturna o alla revisione del codice.

What types of rules should not be used to fail the build?

I soggettivi, per cominciare. Come si applica la regola "Il codice deve essere auto-documentato o ben commentato"? La regola "nessun numero magico"? Queste sono le cose che rimangono meglio nella revisione del codice.

Un'altra categoria è violazioni delle regole a cui è già stata concessa una deroga. Dato qualsiasi base di codice considerevole, ci sarà inevitabilmente qualche pezzo di codice in cui violare lo standard è esattamente la cosa giusta da fare.

Come parte di un piano di miglioramento della qualità del software, recentemente abbiamo codificato una serie di sniff di codice da integrare nel nostro processo di compilazione.

Costruiamo molto, essendo un'applicazione PHP non esiste una vera compilation, quindi la build è in realtà un test unitario / analisi statica / runner e possiamo permetterci di dedicare qualche ciclo a questo.

Abbiamo riscontrato alcuni problemi di qualità del codice e alcuni codici legacy con molti problemi.

Partendo dal presupposto che se non fallisce il commit verrà ignorato, iniziamo a confermare i commit rispetto al nostro standard di codifica 'desiderato', e il fallimento commette errori che non soddisfano lo standard.

Arresto della manutenzione, anche la più semplice correzione di un componente legacy ha richiesto allo sviluppatore di riformattare enormi quantità di risorse e la compilazione è stata interrotta il più delle volte. Inutile dire che abbiamo modificato gli errori in avvertenze e ora sono ignorati e "per lo più" inutili.

Quindi direi questo (imparato da una lunga esperienza).

Assicurati che lo standard della tua base di codice sia abbastanza vicino allo standard che imponi di non richiedere agli sviluppatori di riformattare i volumi di codice, istantaneamente. Oppure .. Sei preparato e ti aspetti un aumento dello sforzo.

Essendo una piccola squadra con un enorme fabbisogno di consegna, non potevamo permetterci di cambiare la squadra in una enorme operazione di ri-fattore. I nostri standard di codifica ora sono per lo più gestiti dalla revisione manuale e l'eredità viene riscritta come parte di un piano di miglioramento continuo.

Quando ho detto che gli avvertimenti sono "per lo più" inutili, beh ora li usiamo per registrare statistiche che ci permettono di misurare kpi che dovrebbero continuare a mostrare miglioramenti.

Quando applichiamo nuovamente il codice annusiamo, inizieremo alla luce e introdurremo qualche sniffata alla volta finché non avremo lo standard applicato.

Dipenderà dal tuo obiettivo e strategia finale .

Forzare tutti gli standard menzionati nel server CI potrebbe sembrare molto redditizio. Tuttavia, potrebbe non essere pratico per il grande team di sviluppo (più di 6 sviluppatori), se viene eseguito su ogni commit sul server. Attendere che il tuo server risponda dopo il commit NON dovrebbe essere un lungo ritardo. Potrebbe potenzialmente causare dei tempi di inattività.

Tuttavia, è del tutto legittimo bloccare un commit se il codice (in realtà il set di modifiche) ha problemi di dipendenza o non viene compilato. Tuttavia, il codice in errore a causa del layout del codice e di alcune convenzioni di denominazione potrebbe essere troppo grave e non una restrizione vitale per le regole di commit del server CI.

Ma è molto probabile che sia una regola utile se applicata durante la serata.

Inoltre, strumenti di ri-factoring possono aiutare nell'implementazione e nell'apprendimento di standard, come l'utilizzo di Resharper o JustCode da parte degli sviluppatori.