Best Practices für die Handhabung von Warnungen

Question

Das Projekt, an dem ich gerade arbeite, generiert jedes Mal, wenn es erstellt wird, mehr als 30 Warnungen. Sie wurden von Anfang an ignoriert. Ich denke aufgrund der fehlenden Richtlinien über Warnungen.

Wie geht das normalerweise? Ignoriere sie überhaupt? Versuche sie alle auf einmal zu beheben (das braucht etwas Zeit)? Oder einfach Stück für Stück auf dem Weg reparieren?

Answer 1

Es gibt nur 30 von ihnen, es ist 2 Stunden Arbeit Mann nur reparieren sie.

Ich stimme überhaupt nicht mit jemandem überein, der sagt, dass eine Frist die Reparatur dieser Warnungen ersetzt. Sie werden später mehr Zeit damit verschwenden, Probleme in den Postcode-Vervollständigungsstufen zu lösen, als wenn Sie Ihre Probleme jetzt behoben haben. Ignorieren Sie Ihren Manager, er ist wahrscheinlich ein Idiot, der seinem Chef gut aussehen will. Anfangsqualität und ein korrektes Design sind wichtiger als seine willkürlichen Fristen (im Rahmen des Zumutbaren). Die Tatsache, dass Sie in erster Linie Warnungen haben, bedeutet, dass jemand mit dem Code schlampig war. Überprüfen Sie die Bereiche, in denen Warnungen vorhanden sind, auf Korrektheit.

Wenn Sie Code-Analyse verwenden oder C/C++ schreiben, sind Warnungen manchmal wirklich nicht gültig. In diesem Fall pragma sie aus (C/C++) oder System.Diagnostics.CodeAnalysis.SuppressMessage. Dies kann automatisch von VS2008 erfolgen.

Ich habe keine .net-Warnungen gesehen, die außerhalb der Codeanalyse nicht gültig waren.

Answer 2

Was ich tatsächlich tue: Mein aktuelles Projekt generiert auch 30-40 Warnungen, und ich ignoriere sie.

Was ich tun sollte: Fix sie, weil einige von ihnen sinnvoll sein könnten.

Answer 3

Best Practices sind, sie alle zusammen zu beheben. Sie sollten die, die Sie jetzt haben, beheben, es mag so aussehen, als würde es einige Zeit dauern, aber sie sind normalerweise kleine Syntaxfehler, die leicht behoben werden können. Dann, wenn Sie beginnen, sie zu bekommen, wenn Sie mehr Code erstellen, können Sie nur diejenigen reparieren, die kommen, wie Sie gehen.

Ich halte auch immer meine Projekte auf Warnstufe 4, die die höchste Ebene der Warnungen ist, so dass, wenn ich kompiliere ich alles beheben kann, dass der Standardcompiler (Visual Studios) denkt, ist falsch.

Answer 4

In unserem Entwicklungsteam muss jede Person ihre Warnungen vor Bier am Freitag aufräumen. Wenn Sie Ihre Warnungen nicht beheben - kein Bier für Sie. Es ist überraschend ein guter Motivator.

Answer 5

Ich empfehle dringend, mit der Einstellung zu bauen, Warnungen als Fehler zu behandeln. Dies wird natürlich dazu führen, dass das Projekt aufhört zu bauen, aber es ist der einzige Weg, um eine vernünftige Fehlerrichtlinie durchzusetzen.

Sobald Sie das getan haben, können Sie die Warnungen überprüfen und einige vernünftige Entscheidungen treffen. Es gibt wahrscheinlich einige Warnungen, die unschädlich sind und die Sie nicht interessieren. Fügen Sie diese daher der Liste der zu ignorierenden Warnungen hinzu. Fix den Rest von ihnen. Wenn Sie jetzt keine Zeit haben, sie alle zu beheben, fügen Sie ein #pragma (oder das C# -Äquivalent) hinzu, um die spezifischen Warnungen zu ignorieren, die in jeder Datei auftreten, und einen Fehler für jede dieser Dateien einzutragen, um sicherzustellen, dass sie später angesprochen werden.

Answer 6

Programmer Rauchen

Ein Mann an der Ecke der Straße steht eine Zigarette nach der anderen rauchte. Eine vorbeifahrende Dame bemerkt ihn und sagt

"Hey, weißt du nicht, dass diese Dinge dich töten können? Ich meine, hast du nicht die riesige Warnung auf dem Feld sehen ?!“

‚Das ist in Ordnung‘, sagt der Mann, schnaufend beiläufig:‚Ich bin ein Computer-Programmierer‘

„So? Was hat das mit irgendetwas zu tun? "

" Wir kümmern uns nicht um Warnungen. Wir kümmern uns nur über Fehler „

;.)

Mein Vorschlag ist zu ignorieren, bis Sie die Lösung gut funktionierend zu bekommen. Dann gehe zum Reparieren der Warnungen; Da die Branche in den meisten Fällen "Terminorientiert" ist;)

Answer 7

Ich denke auch, Sie sollten sie alle zusammen beheben und danach empfehle ich Ihnen, die Compilereinstellung zu ändern, um alle Warnungen als Fehler zu behandeln.

Answer 8

Die meisten Programmierer erstellen ihren Code regelmäßig nach dem Schreiben jedes Konstrukts, nur um zu sehen, ob es korrekt erstellt wird.Dies ist der Zeitpunkt, zu dem Warnungen markiert werden (in VB werden sie auch vom Hintergrund-Build gekennzeichnet).

Ich mache es zu einer Richtlinie, Warnungen bei jedem Build zu beheben. Ich akzeptiere auch keinen Code von meinem Team, der Warnungen kennzeichnet. Nur wenige Arten von Warnungen sind "akzeptabel".

Also meine Politik ist, dass, anstatt sie alle zu einem späteren Zeitpunkt zusammen zu beheben, ich sie beheben, wie sie markiert sind. Als eine Randnotiz, wenn mein Code beginnt, Warnungen zu warnen, ich mich selbst dafür, Code zu schreiben, der meinen Standards nicht entspricht.

Answer 9

Stellen Sie sich vor, Ihr Projekt ist ein Auto.

Was würden Sie tun, wenn jedes Mal, wenn Sie Ihr Auto starten 30-40 Warnlampen blinken?

Wenn Ihr Build-Skript warnt Sie müssen zumindest schauen, was los ist, warum ist diese Warnung dort. Natürlich können Sie Beispiele für das Ausführen von Systemen mit Warnungen haben, aber das ist nicht das, was Sie wollen (ich erwarte).

Wir verwenden einige statische Code-Analysatoren Kalk PMD oder FindBugs (beide für Java). Nach jedem Build beheben wir auch die Warnungen, die von diesen Tools geliefert werden.

Wenn Ihre Warnung aus irgendeinem Grund unwichtig ist, dann schauen Sie, ob Ihre Sprache solche Dinge wie @supressWarning bietet. Eigentlich ist das keine Empfehlung. Es ist nur ein Kommentar.

Answer 10

Jede einzelne Warnung sollte behoben oder speziell deaktiviert werden (mit einer Compiler-Direktive oder einem Code-Konstrukt, das sie beseitigt).
Wenn Sie sich entscheiden, eine Warnung zu ignorieren, ohne sie zu deaktivieren, werden alle Warnungen bedeutungslos - weil Sie sie einfach nicht mehr ansehen. Sie wissen,, dass es einige "okay" Warnungen gibt, also warum überhaupt die Liste betrachten?

Außerdem wird dringend empfohlen, mit der höchsten Warnstufe zu kompilieren und Warnungen als Fehler zu behandeln (dies wird jedoch von Ihrem Compiler gemacht). Wenn der Compiler diese Einstellung nicht unterstützt, versuchen Sie, sie trotzdem zu erzwingen, indem Sie den Ausgabe-/Rückgabewert als Teil des Build-Skripts/-Prozesses betrachten.

Answer 11

Letzten Herbst erbte ich ein neues Java-Subsystem mit 5.000 Zeilen, das 100 ignorierte Warnungen hatte. Wie bei den anderen Befragten hier ist es meine Politik, jede Warnung zu korrigieren, und dabei stellte ich fest, dass drei der 100 echte Programmierfehler waren. Warnungen gibt es aus einem Grund, also ignoriere sie nicht, repariere sie.

Answer 12

Während der Programmierung werden Sie so viele Probleme haben, die nicht durch die Kompilierzeit erfasst werden (die bösen Laufzeitfehler). Der Compiler ist also nicht in der Lage, alle Probleme (auch bekannt als Fehler) zu finden. In einigen Fällen sagt er nur, mmmh könnte ein Problem sein, aber ich weiß es nicht wirklich, bitte überprüfe es (alias Warnung). Sehen Sie sich die Warnung an, beheben Sie sie und fahren Sie fort.

In einigen seltenen Fällen wissen Sie wirklich, was Sie tun und denken Sie nur, ich kenne diese Warnung, aber dieser Code ist korrekt, also belästigen Sie mich nicht mehr. In diesen (wirklich seltenen) Fällen, könnte man vielleicht die Zeile (n) kapseln, die mit einem

// Why you think this warning should be disabled at this point 
#pragma warning disable xxx 
/// ... some code ... 
#pragma warning restore xxx 

und geht und die Compiler erwähnen nicht mehr erwähnt werden.

Werfen Sie einen Blick auf alle Warnungen und beheben Sie sie. Entweder durch Neuprogrammierung oder durch vorübergehende Deaktivierung dieser Warnung.

P.S.Wirklich nicht deaktivieren Sie eine Warnung innerhalb Ihrer Projekteinstellungen. In diesem Fall würden Sie es global deaktivieren (und vielleicht auch für Code, der in Zukunft erstellt wird), oder Sie können keinen Kommentar hinzufügen, warum Sie es deaktiviert haben.

Answer 13

---

Code absichtlich, Gras Moker, als ob Ihre Warnungen auf Trail-Papier ausgerollt wurden. Zerbrechlich wie die Flügel eines Schmetterlings, der sich wie der Kokon eines Seidenwurms anschmiegt - wenn Sie seine Länge mit gedruckten Warnungen vergleichen können und keine Spur von Fehlern hinterlassen, werden Sie gelehrt haben. --master Poh

---

Wenn die Warnungen Sie erhalten nachlassender Dinge, die Sie nicht berücksichtigt hatte, Sie sollten auch weiterhin Warnungen als Fehler zu behandeln, und befestigen Sie sie sofort.

Wenn es sich bei den Warnungen immer um Dinge handelt, die Sie absichtlich getan haben, und der generierte Code das tut, was Sie beabsichtigen, und die Zeit, die Sie beheben müssen, ist nicht zu vernachlässigen, können Sie sie ignorieren brauche ein neues Ritual zur Behebung von Fehlern.

Ein Teil der Fehlerbehebung muss nun die Untersuchung jedes Fehlers umfassen, um festzustellen, ob aktuell ignorierte Warnungen tatsächlich den Fehler gemeldet haben. Halten Sie eine laufende Zählung. Solange die ignorierten Warnungen nicht geholfen hätten, fahre fort. Wenn Sie feststellen, dass Sie zwei sinnvolle Warnungen ignoriert haben, wechseln Sie zurück, um alle Warnungen als Fehler zu behandeln. Gönnen Sie sich etwas Zeit, um sich zu verbessern, und versuchen Sie es erneut.