C/C++-Compiler-Warnungen: Bereinigen Sie Ihren gesamten Code, um sie zu entfernen, oder lassen Sie sie drin?

Lesezeit: 7 Minuten

Benutzeravatar von KPexEA
KPexEA

Ich habe an vielen Projekten gearbeitet, bei denen ich von anderen Code zum Aktualisieren erhalten habe. Meistens kompiliere ich es und erhalte über 1.000 Compiler-Warnungen. Wenn ich Compiler-Warnungen sehe, fühle ich mich schmutzig, also ist meine erste Aufgabe, den Code zu bereinigen und sie alle zu entfernen. Typischerweise finde ich etwa ein Dutzend Probleme wie nicht initialisierte Variablen wie z.

Ich verstehe nicht, warum Leute sie drin lassen und keine perfekt sauberen Kompilierungen ohne Warnungen haben. Übersehe ich etwas? Gibt es einen triftigen Grund, sie einfach zu verlassen? Irgendwelche Horrorgeschichten zu teilen?

  • Vielleicht wäre eine bessere Frage: “Beheben Sie Warnungen oder entfernen Sie sie per Pragma?”

    – ilirit

    8. Oktober 2008 um 21:58 Uhr

  • Als Randnotiz empfehle ich dringend, das wertvolle Buch zu lesen Objektorientierte Reengineering-Muster, von Demeyer et. Al. (kostenloses E-Book erhältlich) für diejenigen, die an Legacy-Codes arbeiten. Er schlägt vor, Änderungen zu priorisieren und an den wertvollsten Änderungen zuerst und iterativ-inkrementell zu arbeiten. Daher hängt die Antwort meiner Meinung nach von der Projektzeitbox und den Prioritäten ab.

    – Masood Khaari

    24. April 2013 um 9:04 Uhr


  • Außerdem sollten Sie für gcc immer mindestens laufen -Wall. ich bevorzuge -Wextraund manchmal -pedantic ist sogar hilfreich.

    – Jonathon Reinhart

    8. Juli 2013 um 5:06 Uhr

Ich würde jede Warnung bereinigen. Sogar diejenigen, von denen Sie wissen, dass sie harmlos sind (falls es so etwas gibt), werden bei dem, der den Code kompiliert, einen schlechten Eindruck von Ihnen hinterlassen.

Es ist eines der “stinkenden” Zeichen, nach denen ich suchen würde, wenn ich an jemand anderem Code arbeiten müsste.

Wenn es sich nicht um echte Fehler oder potenzielle zukünftige Probleme handelt, wäre dies ein Zeichen von Schlamperei

  • +1 zu diesem Beitrag im Allgemeinen. Das einzige, was ich hinzufügen möchte, ist, dass es mit genügend “harmlosen” Compiler-Warnungen viel “Rauschen” erzeugt, das gefährlichere Warnungen verbergen kann.

    – Nick

    8. Oktober 2008 um 17:30 Uhr

  • Recht. Du untersuchst sie alle, reparierst die kaputten. Damit keine neuen übersehen werden, müssen Sie die harmlosen zum Schweigen bringen.

    – wnoise

    8. Oktober 2008 um 19:37 Uhr

  • Direkt am. Ich betrachte alle Warnungen als “visuelles Rauschen”, die meine Aufmerksamkeit von wichtigen Dingen ablenken, also töte ich sie alle, wenn sie auftauchen, sogar die, von denen wir alle sagen: “Ich weiß, ich weiß, es ist kein Problem …”

    – Dan

    3. März 2009 um 22:35 Uhr

  • Ich bin auf Bibliotheken oder Stacks von Drittanbietern gestoßen, insbesondere in eingebetteten Umgebungen mit Flusenfehlern, die ich nicht bereinigen durfte. Das Ergebnis war ein Interger-Überlauf, der bis zur Produktion durchging und zu einer angehaltenen Show wurde. Also räum so viel auf, wie du kannst und wenn die Politik es zulässt.

    – Dubnde

    14. März 2009 um 19:16 Uhr

  • Ja das. Vor nicht allzu langer Zeit habe ich mich nicht darum gekümmert, aber wenn Sie an einer großen Menge Code arbeiten, ist es eindeutig besser: Wenn Sie dies nicht tun, sind neue Warnungen wertlos. Am meisten stört es mich, wenn ich gerade etwas schreibe und eine Variable habe, die nicht verwendet wird noch. Natürlich ist es manchmal unpraktisch: Wenn es bereits 1000 Warnungen gibt, ist das Durchgehen und Korrigieren eine gute Sache, aber es kann möglicherweise nicht die höchste Priorität einnehmen.

    – Jack V.

    2. Oktober 2009 um 9:38 Uhr

Reinigen Sie sie, auch wenn sie nicht auf ein echtes Problem hinweisen. Andernfalls, wenn eine Warnung, dass tut zeigen an, dass ein echtes Problem auftaucht, Sie werden es durch den ganzen Lärm nicht sehen.

Bei meiner Arbeit ist die Compilereinstellung zum Behandeln von Warnungen als Fehler aktiviert. Also keine Warnungen, oder es wird nicht kompiliert 🙂

  • Wie es sich gehört für irgendein Projekt.

    – Andreas

    8. Oktober 2008 um 23:05 Uhr

  • Unter Windows bedeutet dies, dass Sie MFC nicht verwenden können und alle ‘C’-Standardbibliotheksfunktionen in die s_versions von MS ändern müssten

    – Martin Beckett

    8. Dezember 2008 um 15:14 Uhr

  • Ja. Allerdings muss ich hinzufügen, dass ich für meine persönlichen Projekte die Sicherheitswarnungen einfach wegpragma. _s-Versionen sind nicht wirklich sicher und nicht portabel und langsam.

    – Nemanja Trifunovic

    22. Dezember 2008 um 19:41 Uhr

Benutzeravatar von jwfearn
jwfear

Ich stimme zu, dass es am besten ist, alle Warnungen zu beseitigen. Wenn Sie Tausende von Warnungen erhalten, sollten Sie Ihre Korrekturen priorisieren.

Beginnen Sie damit, Ihren Compiler auf die niedrigste Warnstufe einzustellen. Diese Warnungen sollten die wichtigsten sein. Wenn diese behoben sind, erhöhen Sie Ihre Warnstufe und wiederholen Sie den Vorgang, bis Sie die höchste Warnstufe erreichen. Stellen Sie dann Ihre Kompilierungsoptionen so ein, dass Warnungen als Fehler behandelt werden.

Wenn Sie eine Warnung finden, von der Sie vermuten, dass sie ignoriert werden kann, recherchieren Sie, um Ihre Theorie zu bestätigen. Deaktivieren Sie es erst dann und nur so minimal wie möglich. Die meisten Compiler haben #pragma Direktiven, die Warnungen nur für einen Teil einer Datei deaktivieren/aktivieren können. Hier ist ein Visual C++-Beispiel:

typedef struct _X * X; // from external header, not 64-bit portable

#pragma warning( push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )

Beachten Sie, dass dadurch die Warnung nur für eine einzelne Codezeile deaktiviert wird. Mit dieser Methode können Sie in Zukunft auch eine einfache Textsuche in Ihrem Code durchführen, um Änderungen vorzunehmen.

Alternativ können Sie normalerweise eine bestimmte Warnung für eine einzelne Datei oder für alle Dateien deaktivieren. IMHO ist dies gefährlich und sollte nur ein letzter Ausweg sein.

Reinigen Sie sie wenn möglich. Auf einer Multiplattform-/Multicompiler-Codebasis (ich habe an einer gearbeitet, die auf 7 verschiedenen Betriebssystemen mit 6 verschiedenen Compilern kompiliert wurde) ist dies jedoch nicht immer möglich. Ich habe Fälle gesehen, in denen der Compiler einfach ist falsch (HP-UX aCC auf Itanium, ich sehe dich an), aber das ist zugegebenermaßen selten. Wie andere anmerken, können Sie die Warnung in einer solchen Situation deaktivieren.

Oft kann eine Warnung in dieser Version des Compilers zu einem Fehler in der nächsten Version werden (jeder, der von gcc 3.x auf 4.x aktualisiert, sollte damit vertraut sein), also bereinigen Sie es jetzt.

Einige Compiler geben wirklich nützliche Warnungen aus, die unter bestimmten Umständen zu Problemen werden – Visual C++ 2005 und 2008 können Sie vor 64-Bit-Problemen warnen, was heutzutage ein RIESIGER Vorteil ist. Wenn Sie vorhaben, auf 64-Bit zu migrieren, wird durch das Bereinigen dieser Art von Warnungen Ihre Portierungszeit drastisch verkürzt.

Benutzeravatar von Josh Lee
Josh Lee

Es gibt einige Fälle, in denen ich Warnungen im Code belasse oder in denen es nicht möglich ist, sie zu bereinigen (obwohl ich diejenigen entferne, die ich kann). Zum Beispiel:

  • Wenn Sie etwas haben, an dem Sie arbeiten, und Sie wissen, dass es mehr Arbeit/Aufmerksamkeit erfordert, kann es angebracht sein, eine Warnung an Ort und Stelle zu lassen, um darauf hinzuweisen
  • Wenn Sie C++ mit /clr kompilieren, gibt es mehrere Warnungen zu Dingen, die dazu führen, dass nativer Code generiert wird. Es kann umständlich sein, alle diese Warnungen zu unterdrücken, wenn die Codebasis nicht funktional geändert werden kann
  • Warnungen bereinigen, wenn Sie nicht verstehen, was der Fix bewirkt. Ich habe dies ein paar Mal mit PC-Lint-Warnung gemacht und am Ende Fehler eingeführt. Wenn Sie nicht wissen, was die genaue Auswirkung der Änderung ist (zB: Umwandlungen im C-Stil, um Warnungen zu beseitigen), tun Sie es NICHT. Finden Sie die Warnung heraus oder lassen Sie den Code in Ruhe, ist mein Rat.

Wie auch immer, das sind die Fälle aus dem Kopf, in denen es angebracht sein könnte, Warnungen zu hinterlassen.

Benutzeravatar von Greg Rogers
Greg Rogers

Das Schlimmste ist, dass es beim Schreiben von neuem Code schwer zu erkennen ist, ob Sie versehentlich weitere Warnungen eingefügt haben, da es so viele gibt, dass Sie sie sowieso einfach ignorieren.

Das Problem bei der Reinigung aller ist, dass es Zeit braucht, die Sie haben oder nicht haben können. Aber ja, im Allgemeinen sollten Sie so viele wie möglich bereinigen.

1415660cookie-checkC/C++-Compiler-Warnungen: Bereinigen Sie Ihren gesamten Code, um sie zu entfernen, oder lassen Sie sie drin?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy