Ho letto il post di Corrado sul rilascio di Microsoft Source Analysis da parte di Microsoft. Ho provato a installarlo ed effettuare l'analisi di una applicazione Windows Form che devo completare.
Uno strumento di questo tipo è estremamente utile se si vuole realizzare codice pulito, documentato e facile da mantenere. Volevo però sottolineare alcune questioni indicandovi i controlli che ho disabilitato. Ricordo che per modificare le impostazioni dello strumento si deve cliccare con il tasto destro sul progetto nel Solution Explorer e selezionare la voce "Source Analysis Settings".
Vi elenco i controlli che ho disabilitato e se pensate che ho commesso uno sbaglio segnalatemelo:
- SA1101 : PrefixLocalCallsWithThis
Mi sembra molto scomodo anteporre la parola chiave this per accedere a qualsiasi membro (compresi i metodi) della classe. Io mi limito a utilizzarla solamente quando ci sono delle ambiguità nella risoluzione dei nomi, cosa che faccio volutamente nel costrutture della classe. - Documentation Rules
Sono pienamente d'accordo sul fatto che i commenti sono fondamentali per scrivere un codice manutenibile nel tempo. Due sono i punti di vista cioè quello dello sviluppatore di una libreria e quello dello sviluppatore di una applicazione. Il secondo necessariamente utilizzerà diverse librerie per la realizzazione della logica applicativa e il fatto che queste siano documentate è un enorme vantaggio grazie soprattutto al supporto di Visual Studio nel mostrare la descrizione dei membri tramite Intellisense. Quindi lo sviluppatore di una libreria DEVE documentare il suo codice e quindi DEVE attivare questo controllo in Source Analysis. Quello che mi chiedo è se la stessa cosa debba farla lo sviluppatore di una applicazione. Purtroppo l'aggiunta di tag xml prima di un metodo o un membro a mio parere riduce molto la leggibilità del codice a scapito ovviamente della manutenibilità (in futuro, tramite il commento, si capirebbe al volo lo scopo del codice scritto). In genere personalmente preferisco commentare solamente quei metodi che ritengo "complessi" nel senso di non immediata comprensione (anche se ciò può essere sintomo di cattiva progettazione). Mi sembra di aver letto in passato diversi dibattiti sul tema commenti, ma non è mio scopo riaccenderli. Morale della favola io attiverei le Documentation Rules solamente se devo sviluppare una libreria. Mi rendo conto cmq di non aver mai sviluppato una applicazione grande e forse ho una visione limitata del concetto di manutenibilità. - SA1300 : ElementMustBeginWithUpperCaseLetter
Ho disabilitato questo controllo semplicemente perchè non sono abituato a scrivere i metodi con la lettera iniziale maiuscola, inoltre i gestori di evento generati da Visual Studio aggiungono al nome del controllo (con lettera minuscola) il nome dell'evento e quindi non potrei sfruttare la utilissima funzionalità che con un doppio click viene generato automaticamente l'evento essendo costretto a scrivere manualmente il nome del metodo. Forse devo uniformarmi a questa regola ? In effetti è utilizzata sempre nell'implementazione della Base Class Library ! - SA1305 : FieldNamesMustNotUseHungarianNotation
Lo strumento controlla se è stata utilizzata nei nomi la notazione ungherese. Viene visualizzato un errore se il prefisso utilizzato non è presente in una lista modificabile nelle impostazioni.
Direte: perfetto ! Il problema è c'è un vincolo sulla lunghezza del prefisso pari a 2 e quindi non è possibile utilizzare prefissi come lbl, btn, txt che io utilizzo frequentemente nelle applicazioni Windows Form.
Sono quindi stato costretto a disabilitare questo controllo.
- Analyze designer files
Ho disattivato i controlli sui file generati dal designer perchè venivano segnalati errori che ovviamente non è possibile fissare. Un esempio è il designer delle Windows Form che aggiunge i membri privati che rappresentano i controlli della form in fondo alla classe (quindi dopo i metodi) che non dovrebbe essere fatto secondo la regola SA1201 di Source Analysis.
- SA1200 : UsingDirectivesMustBePlacedWithinNamespace
Questa regola consiglia allo sviluppatore di inserire le direttive using all'interno della dichiarazione del namespace e non all'inizio come viene fatto generalmente. Sapete perchè ?