FxCop

pubblicato il 31/05/2006

FxCop è lo strumento gratuito messo a disposizione  di Microsoft per convalidare il codice rispetto alle linee guide della casa di Redmond. L'ultima versione disponibile, la 1.35, necessita del Framework 2.0 per poter "girare", ma è in grado di analizzare alla stessa maniera codice appartenenti alle versioni 1.0, 1.1 o 2.0.

FxCop viene installato come una normale applicazione Windows ma consta in realtà di due eseguibili: l'applicazione vera e propria, che può essere lanciata dal menu Start come un qualsiasi eseguibile Win32, ed una versione a linea di comando che può essere integrata in Visual Studio come un tool esterno oppure lanciata da una shell Cmd (il che lo rende utilizzabile anche da uno di cuei toopl che automatizzano la generazioni di release come ad esempio BuildStudio).

Il programma viene fornito con una (cospicua) serie di regole raggruppate per tema: Design, Globalization (o più propriamente Localizzazione), Interoperability (per l'interfaccia con il mondo COM), Mobility, Naming, Performance, Portability, Security e Usage. Lo sviluppatore o il responsabile è però libero di scegliere se aderire a tutte queste regole oppure escludere singole regole e/o gruppi. Ancora più comoda, almeno secondo me, è la possibilità di definire l'eccezione alla regola, ossia il caso particolare in cui una regola - generalmente valida - debba essere eccezionalmente esclusa dall'analisi.

L'area di lavoro dell'applicazione è suddivisa in tre zone: in alto a sinistra due tree-view che rappresentano il progetto (che a sua volta contiene gli assembly oggetto di analisi) e le regole applicabili. Clickando sul pulsante della toolbar "Add Target for Analysis" si aggiunge un assembly al progetto: fatto ciò è possibile analizzare tutti gli assembly del progetto clickando sul pulsante Analyze.

La zona superiore destra verrà popolata con l'elenco degli (eventuali) errori riscontrati; clickando una volta su un elemento, se ne visualizzeranno i dettagli nella parte inferiore dello schermo; clickando due volte, si aprirà una form di dettaglio, suddivisa in tab, riportante i dettagli dell'errore. I dettagli spesso (ma non sempre) riportano anche il link alla linea di codice che ha generato l'errore: clickandoci sopra si aprirà il Visual Studio, se già non è aperto, permettendo così di correggere direttamente il codice.

Gli errori vengono divisi in due grandi categorie, Breaking e Non-Breaking, a seconda che la risoluzione comporti un "breaking change" o meno (per "breaking change" si intende la necessità di correggere anche il codice che dipende da quello che viene corretto; ad esempio, nmodificando la firma di un metodo sarà necessario modificare anche tutto il codice che richiama quel metodo).

Accennavo prima alla possibilità di definire un'eccezione alla regola: se, ad esempio, abbiamo un metodo Private che proprio non vogliamo trasformare in Shared (regola definita tra quelle di Performance), invece di disabilitare la regola possiamo evidenziare l'errore, clickare sul tasto destro, sceglie la voce Exclude dal menu contestuale ed aggiungere ancghe un bel commento così da rendere chiaro a tutti e per sempre perchè quella regola in quel caso particolare è stata disattesa.

Per quanto mi riguarda, devo ammettere che l'uso regolare di FxCop ha un effetto collaterale imprevisto ma piacevole: costringendomi a rivedere periodicamente il codice, diverse volte mi è capitato di scoprire "bachi" nella logica delle routine prima che potessero manifestarsi (come ad esempio variabili che in certe condizioni non venivano inizializzate - guarda caso il "bug du jour"). Insomma, se da una parte è da mettere in conto che la prima analisi provocherà un bagno di sangue per rendere il codice aderente alle Best Practices, dall'altra parte è bene ricordarsi (sopratutto quando l'impresa sembrerà titanica e verrà la tentazione di mollare tutto) che i benefici in termini di coerenza, solidità e performance ripagano ampiamente del sacrificio.