Compiler-Warnungen

Viele Compiler haben Warnmeldungen, um die Programmierer vor möglichen Laufzeit-, Logik- und Leistungsfehlern zu warnen. Meistens beheben Sie diese schnell, aber was ist mit nicht reparierbaren Warnungen?

Wie gehen Sie mit unfixierbaren Warnungen um? Schreiben Sie einen Teil des Codes neu oder schreiben Sie ihn auf "lange, hackelfreie Weise" oder deaktivieren Sie Warnungen insgesamt? Was sollte die beste Praxis sein?

Was ist, wenn Sie den Code eines anderen Benutzers bearbeiten und dieser Code Warnungen enthält?

Hier ist ein gutes Beispiel: In jQuery werden viele JavaScript-Warnungen angezeigt, da ein Browser der Mozilla-Klasse erkannt wurde. Warum beheben die jQ-Entwickler diese nicht? Wenn Sie zu jQuery beitragen, werden Sie diese Probleme beheben?

Einige Warnungen können normalerweise ignoriert werden, aber wenn Sie dies tun, werden sie sich mit der Zeit vermehren, bis der Tag kommt, an dem es so viele gibt, dass Sie die eine Warnung verpassen, die wirklich wichtig ist, weil sie im Lärm versteckt ist.

Beheben Sie Warnungen sofort (einschließlich des Deaktivierens einzelner Regeln, wenn Sie der Meinung sind, dass dies für Ihren Kontext niemals relevant ist).

Meiner Meinung nach sollten Sie streng mit sich selbst sein. Der Compiler wurde von Experten in der Sprache geschrieben. Wenn sie melden, dass etwas etwas verworren ist (denken Sie an Codegeruch), sollte der Code überprüft werden.

Es ist durchaus möglich, Code zu schreiben, der fehlerfrei und ohne Warnungen kompiliert wird.

Als ich in C und C ++ geschrieben habe, habe ich die strengsten Einstellungen aktiviert, die ich konnte, weil ich wissen wollte, wann etwas für den Compiler keinen Sinn ergab. Wenn ich fertig war mit dem Casting und Überprüfen der Rückgabewerte, würde ich mich freuen, da der Code so korrekt war, wie ich ihn machen konnte.

Ich erhielt gelegentlich Code von jemand anderem, der Warnungen ausspuckte. Die Überprüfung der Quelle ergab, dass sie Dinge ignorierten, die in C eine gute Programmierpraxis darstellten, wodurch der Code zerbrechlich wurde.

Ich glaube, es gibt gute Gründe, die Strenge zu aktivieren und sich die Zeit zu nehmen, um Dinge zu reparieren. Andernfalls ist schlampig. Wenn ich einen Kollegen hätte, der die Warnungen abstellt, würde ich einige Zeit mit ihnen verbringen UND dem Manager erklären, warum das eine wirklich schlechte Sache ist.

Ich würde jede Warnung beheben. Wenn Sie sie ignorieren und sich ansammeln lassen, haben Sie möglicherweise etwas Wichtiges verpasst.

Im Allgemeinen sollten Sie versuchen, den Compiler stumm zu schalten, damit neue Warnungen mehr anzeigen. Diese Warnungen können auf subtile Fehler hinweisen und sollten entsprechend behandelt werden.

Die Festlegung des Kodex anderer Personen hängt stark von Ihrer Unternehmenskultur und dem aktuellen Stand des Kodex ab. Sie können den Code nicht einfach ändern, wenn ein vollständiger Wiederholungszyklus ausgelöst wird, wie dies bei Code spät in der Testphase oder in der Produktion der Fall wäre.

Fragen Sie Ihren Chef und handeln Sie entsprechend.

Jedes Mal, wenn Sie eine Compiler-Warnung sehen, müssen Sie anhalten und darüber nachdenken, ob es wirklich ein Problem ist, beim Kunden in die Luft zu jagen oder etwas, das Sie ignorieren können. Schlimmer noch, die Dinge, die Sie HEUTE ignorieren können, können Dinge sein, die in ein paar Jahren beim Kunden in die Luft jagen, nachdem sich der Code scheinbar anderswo geändert hat.

Korrigieren Sie die Warnungen. Zeitraum. Es ist das oder dokumentieren Sie jedes einzelne von ihnen, mit so vielen Seiten Erklärung, wie nötig ist, um zu beweisen, dass es kein Risiko ist, begleitet von einem unterschriebenen Kaufauftrag über Ihre Lieblingsfreundin (oder Pornostack), wenn sich herausstellt, dass dies der Fall ist War ein Risiko.

Im Allgemeinen soll Ihr Build warnfrei sein. Warnungen sind nicht ohne Grund vorhanden und weisen häufig auf sehr reale Probleme hin. Wenn Sie es sich zur Gewohnheit machen, Compiler-Warnungen zu ignorieren, wird Ihr Build mit der Zeit eine Menge davon haben und Sie werden die eine Warnung verpassen, die durch ein katastrophales Problem verursacht wird, das Ihr Unternehmen teuer werden wird. Wenn Ihr Programm jedoch normalerweise ohne Warnungen kompiliert wird, wird jede neue Warnung sofort bemerkt und kann schnell behoben werden.

Dennoch können Compiler manchmal Warnungen erhalten, die wenig sinnvoll sind und die nicht einfach behoben werden können. Ich begegne dieser Situation jeden Tag bei der Arbeit mit TI CodeComposer, einer Entwicklungsumgebung für TI DSPs. Ich habe C ++ - Code, der ohne Warnungen unter Visual Studio kompiliert wird, der aber zu seltsamen Warnungen in CodeComposer führt, einfach weil TIs Unterstützung für Standard-C ++ besser sein könnte. Glücklicherweise können Sie mit CodeComposer bestimmte Warnungen einzeln deaktivieren. Dies müssen wir tun, wenn der Code, der die Warnung erzeugt, nicht repariert werden kann.

In meinem Fall stammen die Warnungen aus dem PyLint-Tool und ich kann eine Warnung in einer bestimmten Zeile deaktivieren, indem ich in den Kommentaren einen speziellen Text hinzufüge.

In den meisten Fällen mache ich das nicht. In den meisten Fällen ändere ich den Code, um den Vorschlägen von PyLint zu folgen, da PyLint normalerweise korrekt ist. In Abneigungen jedoch Konstrukte, die in der Regel eine schlechte Idee sind, die aber in einem bestimmten Kontext sinnvoll sind. Zum Beispiel beschwert es sich, wenn ich alle möglichen Ausnahmen abfange. Normalerweise ist es richtig, das wäre eine schlechte Idee. In einigen Fällen möchte ich jedoch alle Ausnahmen abfangen, um mir einen Fehlerbericht mit den Details zu senden.

Also: In fast allen Fällen die Hacks loswerden. Wenn der Hack wirklich gerechtfertigt ist, fügen Sie einen Kommentar hinzu, der PyLint sagt, dass er in Ordnung ist.

Einige der Vorteile der Strenge wurden in den anderen Antworten nicht klar angegeben:

1. Wenn alle leicht zu behebenden Warnungen behoben wurden, werden die verbleibenden signifikanten / relevanten Warnungen mit größerer Wahrscheinlichkeit angezeigt.
2. Wenn die relevanten Warnungen rechtzeitig (vor der Veröffentlichung) gefunden und behoben werden, können Fehler vermieden werden, was zu einer besseren Zufriedenheit der Endbenutzer führt
3. Das Lösen der Warnung führt in der Regel zu einem wartbareren und einfacheren Code (z. B. das Eliminieren von Bedingungen, die immer zutreffen).
4. Wenn die Anzahl der Warnungen näher bei 0 liegt, ist es einfach, im Team eine Null-Warnungen-Richtlinie zu vereinbaren, die im CI-System sehr einfach zu automatisieren ist.
5. Beim Lösen von Compiler-Warnungen wird das Verständnis des Programmcodes vertieft, was zu nützlichen Erkenntnissen über die Implementierung führen kann (z. B. andere Fehler entdecken oder Ideen zur Weiterentwicklung des Codes erhalten).
6. Die Erstellung wird schneller, die tägliche Produktivität steigt: IDE / Compiler muss weniger Probleme verwalten und Berichte erstellen, sodass die Kompilierung schneller erfolgt (dies ist nur im Zusammenhang mit Tausenden von Warnungen relevant).

Bei bestimmten Arten von Warnungen gibt es sprachspezifische Unterschiede. Ich denke, es ist wichtig, über das Thema nachzudenken und zu diskutieren und dann einige einzelne Warnungen zu deaktivieren, wenn sie sich völlig nutzlos anfühlen, damit die Strenge erreicht werden kann. Dies wurde in meiner Karriere in mehreren Teams erreicht. Mehr zu meinen Erfahrungen zum Thema

Warnungen und Fehler sind Meldungen, die der Compiler verwendet, um dem Programmierer mitzuteilen, dass "etwas, das Sie geschrieben haben, keinen Sinn ergab". Der Unterschied zwischen ihnen besteht darin, dass der Compiler mit einer Warnung bereit ist, eine Vermutung über die Absichten des Programmierers anzustellen Bei einem Fehler kann der Compiler nicht einmal raten.

Compiler-Fehler werden behoben (ich werde nicht sagen, behoben ), aber allzu oft werden Programmierer (auch erfahrene) die Warnungen ignorieren. Das Problem beim Ignorieren der Warnungen ist, dass der Compiler manchmal falsch vermutet und bei mehr als 1000 Warnmeldungen leicht eine Warnmeldung übersieht, die darauf hinweist, dass der Compiler falsch vermutet.

Aus soziologischer Sicht handelt es sich bei Programmen mit vielen Warnmeldungen um Windows-Broken .