Der (zugegeben etwas pathologische) Quellcode für folgende Ausgabe umfasst kaum ein dutzend Zeilen Code:

   1: 1>D:TestConsoleApplication1ConsoleApplication1Program.cs(88,17,88,18): warning CS0642: Possible mistaken empty statement

   2: 1>D:TestConsoleApplication1ConsoleApplication1Program.cs(84,17,84,19): warning CS0219: The variable 'i3' is assigned but its value is never used

   3: 1>D:TestConsoleApplication1ConsoleApplication1Program.cs(91,13,91,27): warning CS0162: Unreachable code detected

   4: 1>d:TestConsoleApplication1ConsoleApplication1Program.cs(84): warning CA1804: Microsoft.Performance : 'Program.Main(string[])' declares a variable, 'i3', of type 'int', which is never used or is only assigned to. Use this variable or remove it.

   5: 1>d:TestConsoleApplication1ConsoleApplication1Program.cs(85): warning CA1804: Microsoft.Performance : 'Program.Main(string[])' declares a variable, 'i4', of type 'int', which is never used or is only assigned to. Use this variable or remove it.

   6: 1>d:TestConsoleApplication1ConsoleApplication1Program.cs(96): warning CA1811: Microsoft.Performance : 'Program.TestDisposable()' appears to have no upstream public or protected callers.

Man kann sich ausmalen, wie sich das in einem größeren Projekt auswirkt. Und wie “hilfreich” dieser Ausgabe für Entwickler ist, die neu zum Team stoßen und die Anwendung das erste mal übersetzen.

Patrick hat damit zurecht ein Problem:

Remember, the C# compiler gives you a lot of useful information about the robustness of your code… if you’re listening. Don’t ignore warnings.

Warnungen dass eine Variable nicht verwendet wurde, dass Code nicht erreichbar ist und ähnliches, sind keine esoterischen Weisheiten, sondern ernstzunehmende Hinweise.

Patrick geht noch einen Schritt weiter…

They usually only take a few seconds to fix, and fixing new ones when they happen can save you hours. Train yourself to expect the Visual Studio “Error List” window to display “0 Errors, 0 Warnings”, so that any warnings at all make you uncomfortable enough to address them immediately.

… ohne das allerdings ausreichend zu begründen.

Was ist denn mit Warnings, die man im Grunde einfach zur Kenntnis nehmen könnte? “Ja, ich hab’s mir angeschaut, das ist OK so.” Sind die damit nicht erledigt?

Nein, sind sie nicht. Nicht solange sie vom Compiler gemeldet werden. 20 Warnungen dieser Kategorie zwingen mich regelmäßig dazu, wieder darüber nachzudenken. Sie zwingen neue Kollegen dazu, die gleichen Überlegungen anzustellen. Und sie sorgen dafür, dass die 21. Warning, die seit einiger Zeit auftaucht, im Rauschen untergeht und deshalb nicht behoben wird – obwohl sie womöglich unmittelbare Aufmerksamkeit verdient hätte.

Genau deshalb gilt in meinen Projekten eine strikte no-warnings-policy!

Und wenn man den Code nicht ändern will?

• Für Compiler-Warnungen gibt es entsprechende Pragmas, mit der man die Warnung gezielt abschalten kann – womit man auch gleichzeitig dokumentiert, das man sich damit auseinandergesetzt hat und weiß, was man tut.
• Für FxCop-Warnungen gibt es im Visual Studio einfache Möglichkeiten das gleiche zu tun.
• StyleCop habe ich lange abgelehnt, weil mir genau diese Möglichkeit gefehlt hat. Aber auch hier wird die Situation besser.

Wovon ich übrigens kein großer Freund bin, ist die Option “Warnings as errors”. Während der Entwicklung – also während ich gerade Code produziere – sind Warnings völlig normal. Es macht keinen Sinn, formale Anforderungen für halbfertigen Code durchsetzen zu wollen, das behindert mich nur in meiner Arbeit.