Mantenimento delle convenzioni in stile codice per progetti di grandi dimensioni [chiuso]

2

Da un po 'di tempo mantengo uno script ad hoc per verificare lo stile del codice rispetto alle linee guida del nostro progetto.

Sono a conoscenza di AStyle / Uncrustify e li ho usati, ma sono i migliori per una pulizia in codice una tantum, ma non è pratico eseguire tutto il codice attraverso un processo automatico dopo ogni commit.

Per spiegare il problema un po 'di più, sì - abbiamo una documentazione in stile codice, ma gli sviluppatori non sempre seguono esattamente, e non è proprio bello dare loro una posta personale ogni volta che fanno qualche piccolo cambiamento che va contro qualche convenzione.

Quindi ho preso l'approccio per gestire questo tipo di avvertimenti del compilatore, segnalare incoerenze ma lasciare che lo sviluppatore risolva (alcuni di voi potrebbero avere dimestichezza con il controllore di stile pep8 di Python). Una volta ogni tanto facciamo pulizie di stile.

In generale sono molto contento del risultato (a differenza della maggior parte degli strumenti di controllo dello stile), ottieni molta flessibilità - così puoi scegliere dove essere severi e dove essere rilassato rispetto alle convenzioni (evita troppi falsi anche i positivi sono importanti).

Attualmente sto usando Python e Pygments per analizzare il codice sorgente C (anche alcuni C ++ ma principalmente C) e poi il mio script per verificare i risultati con token che soddisfano le nostre convenzioni. Funziona abbastanza bene, non ho bisogno dell'AST completo che puoi ottenere con GCC o Clang per esempio, semplicemente sapendo se il testo è un commento, una stringa, una punteggiatura, un preprocessore ... ecc. È sufficiente (cosa si otterrebbe dalla sintassi evidenziazione o un tokenizzatore di origine).

Ma alla fine ho dovuto scrivere alcune funzioni di utilità per la fonte:

  • estrai il corpo di un blocco tra parentesi.
  • trova le parentesi corrispondenti.
  • identifica i cast.
  • controllo degli spazi bianchi attorno alla punteggiatura.

... niente di veramente avanzato.

Le convenzioni esatte non sono probabilmente così importanti, ma per un esempio qui ci sono alcuni controlli:

  • Posizionamento di parentesi graffe per 'if' assegni di controllo suddivisi in più righe.
  • Posizionamento di break in un'istruzione switch .
  • Spazi attorno a operatori, parentesi, chiamate alle funzioni, dopo le virgole.
  • Indentazione per istruzioni multilinea if
  • Consistenza delle rientranze.

A questo punto sarei interessato ad abbandonare le mie proprie funzioni di utilità, ma ho ancora uno script che controlla lo stile del codice, se c'è qualcos'altro ben mantenuto che risolve problemi simili.

Sarei sorpreso se non ci fossero altre persone che fanno progetti simili per mantenere uno stile sorgente coerente in questo modo, quindi sono interessato a conoscere eventuali alternative disponibili.

Domanda:

Considerando il flusso di lavoro che ho descritto, chiunque può citare le proprie esperienze utilizzando un flusso di lavoro simile, ci sono progetti che già lo fanno, sono interessato a vedere un precedente.

    
posta ideasman42 19.08.2013 - 09:24
fonte

1 risposta

1

A seconda delle lingue, gli strumenti di analisi statica possono esistere o meno. Ad esempio, per C #, c'è StyleCop e la sua integrazione automatica in Visual Studio, che consente di verificare gli errori di stile in un clic (in realtà due clic, ma c'è anche una scorciatoia da tastiera). Utilizzando strumenti di terze parti, può anche essere integrato in molti sistemi di controllo delle versioni, il che significa che solo il codice conforme può essere impegnato.

Per C e C ++, vedi Uno strumento gratuito per controllare il codice sorgente C / C ++ contro una serie di standard di codifica? Non l'ho usato, quindi non so quanto sia bello e se sia possibile integrarlo in un controllo di versione.

In tutti i casi, l'integrazione del controllo della versione è un must, per due motivi:

  1. Se non c'è tale integrazione, non c'è abbastanza pressione sugli sviluppatori per rispettare le regole di stile. Farlo durante la revisione del codice è una perdita di tempo: le recensioni del codice non sono per questo. Infine, ricordare costantemente agli sviluppatori di controllare il loro stile diminuirà inevitabilmente la qualità delle tue relazioni con i tuoi colleghi.

  2. Poiché uno può impegnarsi per alcuni giorni senza essere richiamato per controllare lo stile, è molto più difficile applicare centinaia di regole dopo dieci giorni di lavoro che dieci regole ogni giorno. Il processo dovrebbe essere il più frequente possibile: la tecnica migliore sarebbe spostare l'onere delle regole di stile sull'IDE, ma in realtà gli IDE sono piuttosto timidi quando si tratta di applicare uno stile (anche quando hanno chiesto di farlo, ad esempio attraverso la funzione di formattazione automatica).

risposta data 19.08.2013 - 12:30
fonte

Leggi altre domande sui tag