Statische Code-Analyse - welche sind erste einzuschalten?

Question

Wir verwenden VS2008 mit eingebautem der in statischen Code-Analyse-Regelsatz.
Wir haben eine relativ große C # Lösung bekommen (150 + Projekte) und während einige der Projekte (<20) mit statischer Code-Analyse religiös, sind die meisten nicht. Wir wollen auf alle Projekte statische Code-Analyse starten Durchsetzung, aber alle Regeln ermöglichen eine massive Ablenkung zu unseren aktuellen Projekten schaffen würde. Welche der vielen statischen Code-Analyse-Regeln, die verfügbar sind, sollten wir zum ersten Mal einschalten? Welche Regeln haben den größten Knall für den Dollar? Wenn Sie mir Ihre priorisierten Top 20 geben könnte, würde ich es sehr zu schätzen.
Vielen Dank im Voraus,
--Ed.S.

Answer 1

Die ersten Regeln, die Sie für ein Projekt aktivieren sollten, sind diejenigen, für die Sie keine Verletzungen haben noch nicht in diesem Projekt. Dies ermöglicht es Ihnen neue Probleme Einführung zu vermeiden, ohne dass Sie einen zusätzlichen Bereinigungs Aufwand kostet.

Wie für den Rest, da Sie bereits Code-Analyse auf anderen Projekten verwenden, die beste Eingabe für die Regeln sind am ehesten mit schwerwiegenden Folgen, gebrochen zu werden ist wahrscheinlich die Entwickler, die an diesen Projekten arbeiten. Wenn Sie nicht genug Überlappung zwischen den Projekten müssen aussagekräftiges Feedback von den Entwicklern zu erhalten, möchten Sie vielleicht mit den Regeln zu prüfen, beginnend in der Microsoft Minimum Empfohlen Regeln in Visual Studio 2010 Regelsatz.

Wenn Sie planen, auf tatsächlich bestehende Verletzungen in einem bestimmten Projekt Reinigung, können Sie auf betrachtet FxCop statt VS-Code-Analyse unter Verwendung , bis das Clean-up abgeschlossen ist. Dies würde erlauben Sie Regeln sofort zu aktivieren, während „für clean-up“ Ausschlüsse bestehender Verletzungen außerhalb des Quellcodes zu halten.

Answer 2

Da das Studio sehr ähnlich sind zu FxCop Regeln, kann ich Ihnen sagen, welche ich einschalten würde letzte .

Wenn Internationalisierung nicht am Horizont ist, Globalisierung Regeln deaktivieren.

Ausschalten Leistungsregeln zunächst. Optimieren Sie, wenn Sie müssen.

Setzen Sie die anderen zu Ihrem Team und Ihre Projekte. Schalten Sie individuelle Regeln, die nicht anwendbar sind. Insbesondere muss möglicherweise angepasst werden Regeln benennen.

EDIT: Das Wichtigste ist, Lärm zu reduzieren. Wenn jedes Projekt 200 Warnungen hat und bleibt so für Monate, jeder wird sie ignorieren. Schalten Sie die Regeln, die für Ihr Team wichtig, reinigen Sie den Code bis zu 100% vorbei (oder die Ausnahmen unterdrücken - und wird es Ausnahmen geben, diese sind Richtlinien)., Dann erzwingen halten den Code sauber

Answer 3

Wenn Sie Ihr Projekt gehen lokalisieren / es wird sich in verschiedenen Ländern verwendet werden, dann aktivieren Sie auf jeden Fall die Lokalisierung Regeln. Es wird alle Aufrufe an alle Arten von Format finden / Parse-Funktionen, die Culture nicht angeben. Bugs keine Angabe Culture beteiligt sind schwer in Tests zu finden, aber sie werden Sie wirklich in den Arsch beißen, wenn Ihr Französisch-Client fragen. Warum Ihr Programm nicht / crash funktioniert auf Zahlen mit „“ als Dezimalzeichen

Answer 4

Nach meiner Erfahrung Codeanalyse Warnungen aller Art zeigen, ‚versteckte‘ Fehler oder Mängel in Ihrem Code. Diese Fixierung kann einige echte Probleme lösen. Ich habe nicht eine Liste von Warnungen gefunden, die Ich mag würde deaktivieren.

Stattdessen würde ich sie an einem Projekt zu einer Zeit drehen und alle Warnungen in diesem Projekt beheben, bevor zum nächsten zu bewegen.

Wenn Sie die Dinge deaktivieren möchte ich berücksichtigen nicht die Naming Regeln überprüft (es sei denn Sie eine Bibliothek versenden, APIs oder andere extern exponierten Methoden) und Globalisierung Regeln. (Es sei denn, Ihre Anwendungen machen die aktive Nutzung der Globalisierung). Es hängt ein wenig von Ihrer Situation, den Sinn machen.

Answer 5

Ich bin damit einverstanden etwas mit Jeroen Huinink Antwort .

ich würde sich über alle Regeln, die Sie ein Projekt denken sollten ihnen folgen und beheben, so bald wie möglich. Sie müssen sie nicht alle jetzt reparieren, aber wie Sie durchlaufen und einen Mangel beheben oder ein Verfahren in einem Modul Refactoring, können Sie immer die Probleme durch statische Analyse in diesem Verfahren oder ein Modul gefunden aufzuräumen. Neuer Code in Ihre Regeln hält und bestehende Code sollte so schnell wie möglich in der Einhaltung umgewandelt werden, aber Sie müssen nicht alles fallen zu lassen, um das zu erreichen.

Ihr Entwicklungsteam kann für ein Projekt zu den Themen auch einen Blick und priorisieren sie vielleicht Mängel in Ihrem Tracking-System für die kritischsten Probleme Einreichung, so dass sie schnell angegangen werden und durch den entsprechenden Entwickler.