Applicare gli standard di codifica: quali sono i compromessi dei diversi metodi?

Question

Applicare gli standard di codifica: quali sono i compromessi dei diversi metodi?

#1 da (3 voti)
#2 da (2 voti)

3

Il nostro team ha recentemente concordato alcuni standard di codifica molto chiari e abbiamo bisogno di un mezzo per farli rispettare. Abbiamo già una pratica di integrazione continua matura che include frequenti, piccoli check-in e commit pre-testati.

Stiamo prendendo in considerazione due metodi per implementare un meccanismo di applicazione: un hook SVN pre-commit o una configurazione di build dedicata sul server CI. Ecco i trade-off che abbiamo considerato finora:

Un hook SVN ...
- (-) richiede i privilegi di amministratore del server SVN per l'installazione, che non abbiamo. Possiamo lavorare con l'IT, ma evitare l'overhead è bello.
- (-) punta a uno script, che vorremmo tenere sotto controllo di versione con il resto del prodotto. Non so immediatamente come indirizzare il corretto script di hook, tenendo conto di rami, tag e lavoro sul tronco.
- (-) richiede più lavoro per la segnalazione. Lo script dovrebbe gestire sia la generazione che la pubblicazione del report.
- (+) fornisce un feedback rapido.
- (+/-) fornisce l'applicazione rigida: il codice esegue il check-in o non lo fa. Solitamente una cosa buona (si chiama "enforcement" per una ragione), ma può dare falsi positivi.
La configurazione di build CI ...
- (-) consuma tempo sia sul server CI che su un agente. Potrebbe essere banale, ma si aggiunge.
- (-) introduce una latenza aggiuntiva, rendendo meno immediato il feedback.
- (+) gestisce facilmente gli standard che si evolvono nel tempo, facendo riferimento alla versione dello script esistente in qualsiasi ramo su cui stiamo lavorando.
- (+) fornisce report più semplici. Utilizziamo già il sistema CI per altri report. Aggiungerne uno nuovo sarebbe immediato.
- (+) applicazione configurabile: più semplice per ammorbidire i requisiti, se necessario. Potremmo raccogliere un elenco di violazioni per risolvere fuori banda o fornire avvertenze sugli standard che adottiamo in base alla prova.

Quali sono i compromessi di questi diversi metodi nel far rispettare gli standard di codifica qui?

correlati : Gli standard di codifica devono essere applicati dal server CI? - Aumenta alcuni punti positivi, ma non considera gli hook SVN.

version-control svn coding-standards continuous-integration

posta Lemur 01.05.2014 - 18:59

fonte

2 risposte

Leggi altre domande sui tag version-control svn coding-standards continuous-integration

Come garantire gli invarianti / la logica interna nei metodi setter Best practice per i file di configurazione in un sito Web

score 3 · Answer 1

Hai perso un'altra opzione, esegui l'applicazione degli standard di codifica in fase di compilazione (se stai lavorando con un linguaggio compilato) o dal tuo ambiente di sviluppo (se ne hai uno). In questo modo gli sviluppatori ottengono riscontri immediati riguardo alle loro violazioni degli standard di codifica. All'inizio la maggior parte degli sviluppatori lo troverà fastidioso, ma presto si abitueranno (ho fatto) e inizieranno a programmare nello stile giusto, quindi non violeranno più gli standard di codifica.

Ovviamente avrai anche bisogno di verificarlo da qualche altra parte per assicurarti che non sfugga nulla. Preferirei usare il build server per questo perché

Non sono necessarie modifiche al sistema di controllo della versione, quindi non rallenta i commit ecc.
Hai ancora la possibilità di eseguire il commit del codice anche se non è tecnicamente corretto, quindi è possibile eseguire il commit del codice sulle filiali per mantenere o sperimentare in sicurezza.
La build CI viene utilizzata per notificare agli sviluppatori tutti i tipi di errori, un tipo extra di errore non è troppo inaspettato. Avere gli errori provengono dal commit, tuttavia sembrerebbe essere inaspettato (?).

Infine, se si utilizzano i ganci SVN, gli hook SVN potrebbero non consentire il check-in del codice che viola lo stile di codifica, ma è comunque possibile eseguire il commit del codice interrotto. Questo mi sembra in qualche modo arretrato, visto che probabilmente dovresti preoccuparti di più del codice che non viene compilato o eseguito piuttosto che del codice che viola gli standard di codifica.

score 2 · Answer 2

L'approccio svn-commit hook presenterà problemi di scalabilità che vanno ben oltre a "nessuna tabulazione / spazi iniziali nel file", "giusto tipo di caratteri di nuova riga" e forse "il rientro non è completamente bugnato". Altrimenti, dovrai:

aggiorna il tuo strumento o la configurazione
desidera apportare alcune modifiche banali e urgenti a un file
non riuscire a farlo senza completamente riscriverlo per ripulire tutto ciò che non è più la migliore pratica corrente.

Di conseguenza, probabilmente non sarai mai in grado di aggiornare i tuoi standard di codifica. Che potrebbe essere ok ora, ma farà schifo entro il 2020 o giù di lì ...

Tenuto a quel livello semplice, i ganci sono comunque piuttosto utili. Mantenere tali problemi completamente fuori dalla cronologia può semplificare le differenze.