Perché non si applicano gli strumenti di analisi refactoring?

Question

FxCop e < a href = "http://www.ndepend.com/" rel = "nofollow noreferrer"> NDepend molto in questo momento, e continuo a vedere gli oggetti loro rapporti generano, che sono "sbagliato" ¹ e chiedendo a me stesso, perché non possono questi strumenti basta andare e fare quelle correzioni da essi proposti?

ho un po 'sono molto difficili da capire, ma qualcosa di simile i campi dovrebbero essere contrassegnati in sola lettura può essere facilmente applicato con le informazioni lo strumento ha. Tuttavia per me significa andare allo strumento, trovando l'elemento poi mettendo il codice in etc ... richiede molto tempo anche per gli oggetti più piccoli.

Vorrei anche essere felice se dovessi confermare ogni cambiamento, in un modo simile a come CodeRush Xpress fa con una certa refactoring di esso.

Quindi non v'è una ragione per cui questi strumenti non fanno questo?

---

¹ sbagliato è relativo qui, dal momento che una cosa del genere la classe 1700 del FxCop errori che sono tutti sulla denominazione non sono male il codice, ma non rendere più difficile per i nuovi sviluppatori a cimentarsi il codice.

Answer 1

Forse perché non c'è sempre - o anche la maggior parte del tempo - un unico, corretta scelta del refactoring da fare. Di solito ci sono decine di modi di refactoring del codice in modo, che la quantità di avvisi sarà ridotto, ma quello che in realtà è giusto per il progetto è qualcosa uno sviluppatore dovrebbe decidere.

Answer 2

Rob, questo è qualcosa che (la squadra NDepend) stiamo pensando per il lungo termine. Ma il codice toccante è un dominio molto più sensibile di un semplice analizzarla. E come ha detto Rytmis, spesso non c'è solo una scelta sola per il refactoring.

Certamente l'opzione migliore sarà quella di lasciare che NDepend inviare i comandi di refactoring ad un solido refactorer esistente, come R #. Ma questa è pura supposizione al momento.