Ist es empfehlenswert, Warnungen und Hinweise zu vermeiden?

Ich arbeite im Allgemeinen mit PHP-Warnungen und deaktivierten Hinweisen, da ich an vielen Projekten arbeite, in denen es bereits in der Live-Produktion ist. Wenn ich nun die Warnungen und Hinweise auf diesen Live-Produktions-Websites einschalte, werden sie mit ihnen überladen.

Bei den Projekten, an denen ich zu Hause und vor Ort arbeite, versuche ich normalerweise, ALLE Warnungen und Hinweise zu beseitigen. Manchmal gibt es keine Lösung, wenn ich keine Benachrichtigung habe. Deshalb muss ich mich erst mit der Benachrichtigung befassen, bevor ich mich entscheide, sie vollständig auszuschalten.

Letztendlich weiß ich nicht, ob ich meine Zeit damit vergeude, alle Warnungen und Hinweise loszuwerden, oder ob ich dies tatsächlich zum Wohle des Guten tue.

Daher meine Frage, ist es eine gute Praxis, Warnungen und Hinweise insgesamt zu vermeiden, oder spielt es wirklich keine Rolle?

php warnings

— Audite Marlow
quelle

"Manchmal gibt es keine Lösung, um keine Benachrichtigung zu erhalten" Es ist eine Weile her, dass ich PHP verwendet habe, aber ich kann mich nicht erinnern, auf Fälle gestoßen zu sein, in denen Sie die Benachrichtigung / Warnung vermeiden oder zumindest lokal unterdrücken@ könnten .

— CodesInChaos

Das überzeugendste Argument, das ich gesehen habe, ist: "Diese Botschaften existieren aus einem bestimmten Grund. Wenn wir uns darauf einstellen, eine Flut von Warnungen zu ignorieren, übersehen wir tatsächliche Probleme, die möglicherweise abgewendet wurden." Mit anderen Worten, wenn während des normalen Betriebs keine Warnungen oder Hinweise angezeigt werden, sind Warnungen oder Hinweise ein Zeichen für potenzielle Probleme. Wenn alles nur Lärm ist, werden Sie Probleme erst nach SHTF bemerken (und wahrscheinlich auch nach den Kunden).

— Piskvor

Die Verwendung von @ zum Unterdrücken von Benachrichtigungen wird im Allgemeinen als eine schlechte Sache angesehen, obwohl dies häufig vorkommt. Es ist schlimmer als einfach alle Benachrichtigungen auszuschalten, da Sie jetzt ein potenzielles Problem versteckt haben. In 15 Jahren PHP-Programmierung bin ich noch nicht auf einen Fall gestoßen, in dem ich einen Hinweis in dem von mir kontrollierten Code unterdrücken musste.

— Cerad

Schalten Sie einfach die Anzeige dieser Hinweise aus oder tun Sie dies error_reporting(0);? Ich habe immer verwenden error_reporting(E_ALL);und der einzige Unterschied zwischen Entwicklung und Produktion ist ini_set('display_errors', 'on');vs ini_set('display_errors', 'off');. Ich bemühe mich immer, Hinweise und Warnungen zu korrigieren, solange der Code noch in meinem Kopf ist. Ich überprüfe die Protokolle in meinem Produktionssystem regelmäßig, um festzustellen, ob zusätzliche Warnungen und Hinweise vorhanden sind, die ich möglicherweise übersehen habe.

— MonkeyZeus

Ich stimme sehr mit @Cerad überein @. Nach Jahren und Jahren der PHP-Programmierung habe ich diesen Operator nicht benutzt. Nicht einmal. Noch nie. Dies verbirgt nicht nur potenzielle Probleme, sondern hat auch Auswirkungen auf die Leistung: Im Hintergrund deaktiviert PHP die Fehlerberichterstattung, bevor der Code aufgerufen wird -> ruft den Code auf -> setzt ihn auf seinen ursprünglichen Wert zurück. Diese Schritte sind teuer, wenn @Ihr Code Dutzende oder Hunderte von Schritten enthält.

— Radu Murzea

Antworten:

Wenn ich die Warnungen und Hinweise auf diesen Live-Produktions-Websites einschalte, werden sie mit ihnen überladen.

Bei der Entwicklung, beim Testen und bei der Qualitätssicherung sollten die Warnungen immer auf der höchsten Stufe aktiviert sein, jedoch nicht in der Produktion. Wenn es sich um eine Hundefutter-Anwendung handelt, dh um eine Anwendung, die Sie selbst verwenden, sollten Sie sie auch in der Produktion aktivieren.

Grundsätzlich gilt: Lassen Sie sie in den Fällen einschalten, in denen die Person, die sie sieht, in der Lage ist, etwas dagegen zu unternehmen (der Entwickler in Entwicklung und Test kann sie selbst beheben, der Tester in der Qualitätssicherung kann einen Fehler melden, und wenn dies der Entwickler ist auch der Benutzer, dann kann er es auch in der Produktion reparieren), aber schalten Sie sie nicht ein , wenn die Person, die sieht, nichts dagegen tun kann (ein Benutzer in der Produktion, der nicht einmal programmieren kann).

Im Idealfall möchten Sie auch Warnungen als Fehler behandeln, aber das funktioniert nur, wenn keine vorhanden sind ;-) Beachten Sie dies jedoch als Ziel! Wenn es möglich ist, diese Funktion auf Dateibasis zu aktivieren / deaktivieren, aktivieren Sie sie für alle neuen Dateien und aktivieren Sie sie für alle warnfreien Dateien. Schalten Sie sie niemals wieder aus, wenn Sie sie einmal aktiviert haben.

Was tun gegen die Überlastung?

Sie erstellen eine Liste aller Warnungen und Hinweise und befolgen dann die folgenden Regeln:

Fügen Sie der Liste unter keinen Umständen eine neue Warnung hinzu. Jedes neue Stück Code, jede Bearbeitung, jede Änderung, jeder Patch, jedes Commit darf keine neuen Warnungen einbringen, sondern nur diese beheben .
Korrigieren Sie bei jeder Berührung eines Codeteils alle Warnungen in diesem Codeteil. (Die Boyscout-Regel: Verlassen Sie den Campingplatz immer in einem besseren Zustand, als Sie ihn vorgefunden haben.) Auf diese Weise kann der unwichtige Code voller Warnungen bleiben, aber der wichtige Code wird mit der Zeit sauberer. "Stück Code" kann eine Funktion, eine Klasse, eine Datei sein. Sie können diese Regel auch lockern, um mindestens eine Warnung zu beheben. Der Punkt ist: Repariere sie so, wie du sie findest.

Hinweis: Für beide ist eine Art Protokolldatenbank und ein Protokollfiltermechanismus erforderlich. Beachten Sie auch, dass "Protokolldatenbank" und "Protokollfiltermechanismus" nur eine Textdatei sein können und grep.

Das ist das Wichtige. Ohne die Datenbank wissen Sie nicht, wann Sie eine neue Warnung hinzufügen, und ohne die Filterung haben Sie immer noch das Überlastungsproblem.

Hinweis Nr. 2: Dies funktioniert nicht nur für Warnungen, sondern auch für Stilprüfungen, Komplexitätsmetriken, Codeabdeckung, statische Analysetools usw. Grundsätzlich gilt:

Fügen Sie keine neuen Probleme hinzu.
Beheben Sie alte Probleme, während Sie über sie stolpern.

Dies ermöglicht eine einfache Priorisierung: Code, der häufig bearbeitet wird und daher leicht zu lesen und zu warten ist, wird mit der Zeit besser. Code, der nicht oft angerührt wird, wird nicht besser, aber das ist in Ordnung, weil sich sowieso niemand darum kümmern muss. Und zumindest wird es nicht schlimmer werden.

Natürlich hindert Sie nichts daran, Zeit speziell zuzuweisen, um nichts anderes zu tun, als Warnungen aufzuspüren und zu töten. Es ist nur so oft, dass dies wirtschaftlich nicht vertretbar ist, und es ist Ihre Aufgabe als Ingenieur, dies zu berücksichtigen. "Ein Ingenieur ist einer, der mit einem Dollar bauen kann, was jeder Dummkopf mit zwei bauen kann."

— Jörg W. Mittag
quelle

Ein weiterer Grund, Warnungen und Fehler, die den Benutzer ungefiltert erreichen, auszuschalten: So informativ eine Warnung für den Entwickler ist, kann sie vertrauliche Informationen (Dateinamen, Namen anderer beteiligter Server, Struktur der verwendeten SQL-Abfragen, ...) preisgeben. )

— Hagen von Eitzen

Warnungen in der Produktion sollten sich auf die Protokolle beziehen, nicht auf den Benutzer! Fehler sollten in die Protokolle geschrieben werden, nicht an den Benutzer. Eine Website, die Fehler nicht abfängt, protokolliert und stattdessen eine benutzerangepasste Fehlerseite bereitstellt, ist nicht produktionsbereit. PHP macht es sehr einfach, dies falsch zu machen, aber Sie sollten es trotzdem richtig machen.

— Hobbs

Wenn Warnungen und Hinweise aus Ihrem Code stammen, beheben Sie dies auf jeden Fall. Meiner Erfahrung nach ist dies bei 95% vielleicht harmlos, bei 5% handelt es sich jedoch um ein echtes Problem, das zu unzähligen Stunden Jagen führen kann.

Wenn sie aus dem Code eines Drittanbieters stammen, den Sie aus dem einen oder anderen Grund verwenden müssen, haben Sie im Allgemeinen keine große Auswahl.

Eine andere Frage: Wenn Ihre alte Codebasis wirklich groß ist, können Sie alten Code als Drittanbieter behandeln, aber der neue Code muss warnungsfrei sein.

— Alexander Pogrebnyak
quelle

Ich arbeite in Java / Eclipse, was sich offensichtlich von PHP unterscheidet, aber ich stelle normalerweise fest, dass die Warnung entweder durch 1) etwas ausgelöst wird, das kompiliert wird, aber ich habe einen offensichtlichen Fehler gemacht, oder 2) etwas, das jetzt in Ordnung ist, aber auf der Straße schlecht sein wird

— CorsiKa

@corsiKa Ich war übersetzen Ihren Kommentar zu PHP , aber ich erkennen , dass nur ein Wort geändert werden muß.

— wizzwizz4

Es sei denn, diese Warnungen stammen von StyleCop und beziehen sich auf die Reihenfolge Ihrer usingAussagen ...

— Dan Pantry

Es ist wichtig. Eine Warnung könnte Ihre Tests nicht brechen oder sogar für eine Weile in der Öffentlichkeit auftauchen - aber es könnte ein Symptom für einen drohenden Fehler sein. Ich entwickle derzeit hauptsächlich in C # / C ++ und habe eine definierte Strategie, um Warnungen aus unserer Codebasis zu entfernen und zu verhindern. Zum Glück ist es keine Raketenwissenschaft =).

Wenn die Sprache, in der Sie arbeiten, in der Warnungen als Fehler behandelt werden können und die Warnstufen variabel sind, würde ich Folgendes tun:

Verringern Sie die Warnstufe gerade so weit, dass Sie keine Warnungen erhalten. Wenn Sie sich auf der niedrigsten Warnstufe befinden und weiterhin Warnungen angezeigt werden, versuchen Sie, diese zu beheben. Wenn Sie sie nicht reparieren können, sind Sie vorerst fertig, aber hoffentlich können Sie sie reparieren. Groß.
Da Sie jetzt keine Warnungen mehr haben (höchstwahrscheinlich bei niedriger Warnstufe), schalten Sie den Schalter um und behandeln Sie alle Warnungen als Fehler.
Versuchen Sie, die Warnstufe zu erhöhen und alle neuen Warnungen zu beheben. Wenn dies nicht möglich ist, verringern Sie die Warnstufe, aber behandeln Sie Warnungen nicht als Fehler.

Ich finde, dass dies nicht nur Warnungen aus meinem Code herauswirft - es hält sie auch fern .

— PerryC
quelle