Domanda

Mi piace l'analisi del codice statico e l'applicazione delle regole di StyleCop . Tuttavia, è gravemente carente in diversi dipartimenti chiave.

  • L'aggiunta di nuove regole non è ufficialmente supportata e da quello che sento piuttosto difficile.
  • Automatico "fissaggio" di banali regole violazioni sarebbe bello! Forse non con la denominazione variabile, ma con l'ordinamento dei metodi (statico, ecc.), Ciò comporterebbe un enorme risparmio di tempo.
  • Microsoft " taglia unica per tutti " l'approccio a StyleCop è piuttosto restrittivo. Vorrei avere un set personalizzato di regole per i nostri standard interni.

Esiste un prodotto così commerciale là fuori?

È stato utile?

Soluzione

L'aggiunta di regole è, o sarà, ufficialmente supportato :

  

Come promesso, rilasceremo anche   Documentazione SDK per StyleCop   spiegando come creare regole personalizzate   e come integrare lo strumento in   ambienti di build personalizzati. L'SDK   la documentazione è attualmente in fase finale   recensione e speriamo di rilasciarlo molto   presto.   - JasonAll

In termini di "quotazioni interne" stile, mi sono avvicinato piuttosto disabilitando una manciata di regole StyleCop:

  • Intestazioni dei file (SA1633-SA-1640)
  • Ordinamento del codice (SA1200-SA1202)
  • Richiesta " questo " (SA1101)

Puoi farlo a livello globale modificando il file Settings.StyleCop nella directory di installazione, anche se ho adottato l'approccio di metterne uno alla radice del nostro albero dei sorgenti in ciascun progetto.

L'effetto finale è molto quello che vogliamo. Ci sono alcuni "interni". scelte che sarebbe bello segnalare, ma anche senza di loro StyleCop ci sta offrendo molto valore.

Altri suggerimenti

StyleCop per ReSharper potrebbe aiutarti (dovrai acquistare ReSharper, ma il plug-in è libero):

  

StyleCop per ReSharper è ora disponibile   completo in quello che ha raggiunto   parità di funzionalità con StyleCop 4.3.

     

Esistono 148 regole StyleCop.

     
      
  • 38 di questi devono essere riparati manualmente (normalmente perché devi digitare   testo descrittivo o rinominare le variabili).
  •   
  • Delle restanti 110 regole 58 sono state risolte da R # Code Cleanup (silenzioso   modalità).
  •   
  • Dei 52 rimasti, abbiamo regole di pulizia del codice che risolvono tutto   loro automaticamente.
  •   
     

Forniamo anche 106 Correzioni rapide che   fornire correzioni del menu contestuale sul posto   per violazioni delle 110 regole che   può essere risolto automaticamente

Spediamo anche un file di impostazioni di condivisione dello stile di codice ReSharper compatibile con StyleCop " che configura ReSharper per formattare automaticamente il codice in un modo compatibile con StyleCop.

C'è Gendarme da Mono, sebbene sia Open Source, non commerciale.

Un'alternativa o un buon complemento a StyleCop sarebbe utilizzare lo strumento commerciale NDepend . Con questo strumento è possibile scrivere la regola del codice sulle query LINQ (ovvero CQLinq) . Dichiarazione di non responsabilità: sono uno degli sviluppatori dello strumento

Più di 200 regole di codice sono proposte di default, queste includono design , architettura , qualità del codice , evoluzione del codice , convenzioni di denominazione , codice morto , utilizzo di .NET Fx ...

CQLinq è dedicato alla scrittura di regole di codice che possono essere verificate dal vivo in Visual Studio , oppure che possono essere verificati durante il processo di compilazione e riportati in un rapporto HTML / javascript .

La forza di CQLinq su StyleCop o anche su FxCop è che è semplice scrivere una regola di codice e ottenere immediatamente . Le strutture sono proposte per sfogliare gli elementi di codice abbinati. Concretamente, sembra così:

Regola codice CQLinq

Agent Smith è molto carino. Richiede Resharper.

Dai un'occhiata a CodeIt.Right da Submain.

Scrivo spesso test unitari per riflettere sui miei tipi e verificare la presenza di violazioni delle mie regole personalizzate.

Ecco un esempio per verificare che alcuni tipi siano immutabili: http://blogs.msdn.com/kevinpilchbisson/archive/2007/11/20/enforcing-immutability-in-code.aspx

Eccone un altro, per le regole sulla denominazione di unit test: http://jbazuzicode.blogspot.com/ 2008/11 / keeping-test-fixture-e-class-names.html

EDIT: il secondo collegamento sembra essere perso nelle sabbie del tempo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top