it-swarm-eu.dev

Ist auskommentierter Code wirklich immer schlecht?

Praktisch jeder Text zur Codequalität, den ich gelesen habe, stimmt zu, dass auskommentierter Code eine schlechte Sache ist. Das übliche Beispiel ist, dass jemand eine Codezeile geändert und die alte Zeile dort als Kommentar belassen hat, anscheinend um Leute zu verwirren, die den Code später lesen. Das ist natürlich eine schlechte Sache.

Aber ich finde mich oft dabei, auskommentierten Code in einer anderen Situation zu hinterlassen: Ich schreibe einen Algorithmus für Computergeometrie oder Bildverarbeitung. Um diese Art von Code zu verstehen und mögliche Fehler darin zu finden, ist es oft sehr hilfreich, Zwischenergebnisse anzuzeigen (z. B. eine Reihe von Punkten auf dem Bildschirm zu zeichnen oder eine Bitmap-Datei zu speichern). Das Betrachten dieser Werte im Debugger bedeutet normalerweise das Betrachten einer Wand aus Zahlen (Koordinaten, Rohpixelwerte). Nicht sehr hilfreich. Jedes Mal einen Debugger-Visualizer zu schreiben, wäre übertrieben. Ich möchte den Visualisierungscode nicht im Endprodukt belassen (dies beeinträchtigt die Leistung und verwirrt normalerweise nur den Endbenutzer), aber ich möchte ihn auch nicht verlieren. In C++ kann ich #ifdef Verwenden, um diesen Code bedingt zu kompilieren, aber ich sehe keinen großen Unterschied zwischen diesen:

/* // Debug Visualization: draw set of found interest points
for (int i=0; i<count; i++)
    DrawBox(pts[i].X, pts[i].Y, 5,5);
*/

und das:

#ifdef DEBUG_VISUALIZATION_DRAW_INTEREST_POINTS
for (int i=0; i<count; i++)
    DrawBox(pts[i].X, pts[i].Y, 5,5);
#endif

Die meiste Zeit lasse ich den Visualisierungscode einfach auskommentiert, wobei ein Kommentar besagt, was visualisiert wird. Wenn ich den Code ein Jahr später lese, bin ich normalerweise froh, dass ich den Visualisierungscode einfach auskommentieren und buchstäblich "sehen, was los ist".

Sollte ich mich dabei schlecht fühlen? Warum? Gibt es eine überlegene Lösung?

pdate: S. Lott fragt in einem Kommentar

Verallgemeinern Sie den gesamten kommentierten Code irgendwie, um sowohl Debugging als auch sinnlosen, veralteten Code einzuschließen? Warum ziehen Sie diese übermäßig verallgemeinerte Schlussfolgerung?

Ich habe kürzlich Robert Martins "Clean Code" gelesen, in dem steht:

Nur wenige Praktiken sind so abscheulich wie das Auskommentieren von Code. Tu das nicht!.

Ich habe mir den Absatz im Buch noch einmal angesehen (S. 68), es gibt keine Qualifikation, keine Unterscheidung zwischen verschiedenen Gründen für das Auskommentieren von Code. Also habe ich mich gefragt, ob diese Regel zu allgemein ist (oder ob ich das Buch falsch verstanden habe) oder ob das, was ich tue, eine schlechte Praxis ist, aus irgendeinem Grund wusste ich es nicht.

53
nikie

Der Vorteil von # ifdefs im Gegensatz zum Auskommentieren besteht darin, dass Sie (bei großen Projekten) die Definitionen in einer make- oder config-Datei auflisten können - und daher nicht manuell Kommentare abgeben, erstellen und dann erneut erstellen müssen -Kommentieren Sie sie, wenn es an vielen Orten ist. Der Nachteil dabei ist, dass das Ändern der DEFINE-Werte des Projekts normalerweise bedeutet, dass das Ganze neu erstellt wird, nicht nur geänderte Dateien.

Obwohl ... ich denke, der "auskommentierte Code ist eine schlechte Sache" bezieht sich wirklich auf toter Code, den die Leute aus irgendeinem Grund einfach nicht löschen wollten (Angst, etwas wegzuwerfen, das sie ausgegeben haben Zeit vielleicht?). Es geht nicht wirklich um die Situation, die Sie für sich haben.

58
TZHX

Wenn es auskommentiert ist, kann es verrotten: Wenn Sie plötzlich entscheiden, dass Sie es erneut benötigen, stellen Sie fest, dass es nicht mehr kompiliert wird oder neu geschrieben werden muss, damit es mit anderen Dingen übereinstimmt, die sich in der Zwischenzeit geändert haben.

Wenn Sie den Code belassen, aber so, dass der Compiler ihn bei Bedarf nicht optimieren kann, profitieren Sie davon, dass Sie den Code auf dem neuesten Stand halten nd ohne die hinzugefügte Binärdatei leiden zu müssen Größe oder Laufzeitleistung.

In C besteht beispielsweise die Gefahr der Fäulnis:

/*
doSomeDebugStuff();
*/

Und so ist das:

#if 0
doSomeDebugStuff();
#endif

Dies ist jedoch gut, da es immer vom Compiler auf Gültigkeit überprüft wird, aber wahrscheinlich weg optimiert wird:

if (0)
{
  doSomeDebugStuff();
}

Bearbeiten: Wie andere betonen, ist es sogar noch besser, ein aussagekräftiges Symbol anstelle von 0 Für den Test zu verwenden.

25
Graham Borland
// The problem with commented out code is that it can hide what you're actually
// trying to say in a wall of text.  Syntax highlighting may help, but you're 
// still left with this huge ginormous wall of text in front of you, searching
// through it for what the actual answer is. You'd think that mentally it'd be 
// really easy to disregard the comments, but in actual usage, it's a lot harder
// than a one Word answer that can tell you what you're looking for. It's tough.
/* Sometimes they'll even through you off with different comments. */ Yes.
// It's really tough to deal with people that don't like to use source control, 
// that would rather comment lines and lines of code instead of deleting the 
// code and checking in revision.  Cue irrelevant paragraph about the reason why 
// I wrote this instead of just deleting the entire block and replacing it 
// with my intention. Maybe I was hedging my bets? Cue misspelled wrod.  
18
George Stocker

Ich denke, es muss unterschieden werden zwischen auskommentiertem Code, der veraltet ist, und Code, der nur in einem Debug-Build (oder einem anderen "speziellen" Build, der unter bestimmten Bedingungen kompiliert wird) verwendet wird. Letzteres ist eine gängige Praxis, und daran ist nichts auszusetzen.

Ersteres sollte nicht in einer Quelldatenbank vorhanden sein, da das Versionskontrollsystem das veraltete Material nachverfolgt, falls Sie es jemals zurückerhalten möchten.

15
Alex Budovski

Es gibt fast kein "immer" in der Codierung :) Wenn Sie genug über die Gründe für eine Richtlinie wissen und wirklich gute Gründe haben, sie zu brechen, dann tun Sie dies.

Zum Beispiel kommentiere ich Code aus, wenn ich "Kamikaze-Refactoring" mache, und benötige eine visuelle Erinnerung, um Dinge wieder hinzuzufügen oder mich daran zu erinnern, wie der alte Code eine Weile funktioniert hat. In solchen Fällen ist es wichtig, dass Sie die Kommentare später löschen. Andernfalls wird Ihr Code einfach unübersichtlich.

11
Homde

Manchmal fügen Sie Code in Ihre Kommentare ein, um zu zeigen, wie eine Klasse verwendet wird - dies unterscheidet sich stark von dem früher ausgeführten Kommentar-Code.

8
Ian

Ich mache viele Codeüberprüfungen und finde, dass es keine wirkliche Entschuldigung für kommentierten Code gibt, unabhängig vom Grund. Wenn Sie den kommentierten Code für Debugging-Zwecke verwenden, können Sie einen Trace-Mechanismus erstellen, der im Release-Modus deaktiviert ist oder über Trace-Ebenen verfügt (immer gut, um in einer Release-Version verfolgen zu können), oder Sie können einfach einen Debugger verwenden.

Kommentierter Code ist schlecht, da es sehr verwirrend ist, den Code zu lesen, wenn andere Personen den Code lesen - insbesondere wenn Sie gestresst sind, einen Fehler zu beheben, wenn der ursprüngliche Autor nicht im Urlaub ist -, insbesondere wenn der Fehler falsch ist // am Anfang der Zeile platziert ... selbst mit/* können Sie versehentlich etwas kommentieren, das dort hätte sein sollen - oder nicht.

Um Ihren Code sauber und lesbarer zu halten, entfernen Sie kommentierten Code. Es ist bereits schwierig, Programme zu lesen, da er Code lesen muss, der möglicherweise von Bedeutung ist oder nicht.

3
AndersK

Ja, so ist es.

Selbst wenn Sie Debugging-Code haben, den Sie in Ihrer Produktionsversion nicht möchten, sollten Sie ihn nicht auskommentieren. Die Verwendung von #ifdef Ist besser, da Sie das Debuggen dann einfach mit einem #define - Makro oder durch eine separate Build-Konfiguration ein- und ausschalten können. Dies ist definitiv besser als in den Code zu gehen und jeden Block des Debugging-Codes manuell zu kommentieren/zu kommentieren.

Und wenn Sie Flexibilität benötigen, um einige Debugging-Blöcke zu aktivieren, andere jedoch nicht, sollten Sie die Debugging-Blöcke in "Debug-Ebenen" gruppieren.

Eine bessere Lösung wäre, den Vorprozessor überhaupt nicht zu verwenden und muttersprachliche Funktionen wie Konstanten und if-Anweisungen zu verwenden. Also statt

#define DEBUG0
#ifdef DEBUG0
  // debugging code
#endif

du kannst haben

const bool DEBUG0 = true;
if(DEBUG0)
{
  // debugging code
}

Der Vorteil gegenüber der Verwendung des Vorprozessors besteht darin, dass Ihr Debugging-Code immer vom Compiler überprüft wird. Dies verringert die Wahrscheinlichkeit, dass es verrottet, wenn Sie den Code um es herum ändern.

Sie würden keinen Leistungseinbruch erleiden, wenn Sie das boolesche Flag auf false setzen, da moderne Compiler nicht erreichbaren Code optimieren. Im schlimmsten Fall wird möglicherweise eine Compiler-Warnung angezeigt.

2
Dima

Ich denke nicht, dass das, was du tust, absolut schlecht ist, aber ich denke, du solltest zumindest ein paar tatsächliche Kommentare dazu haben, um zu erklären, was es tut, warum und wie und wann es zu verwenden ist es.

Persönlich würde ich normalerweise so etwas in eine Art IF DebugMode = TRUE-Typ-Aufwand um den fraglichen Code setzen und diesen als Befehlszeilen-/Startparameter festlegen. Für mich ist es einfacher zu erkennen, dass der Code deshalb vorhanden ist und wie er festgelegt wird, obwohl in Ihrer Instanz möglicherweise Leistungsprobleme auftreten, selbst bei dem kleinen Vergleich, den Sie vermeiden möchten.

Also würde ich wahrscheinlich sehen, was Sie als notwendiges Übel tun, anstatt durch und durch falsch zu sein. Wenn Sie einen Weg finden, es zu rationalisieren, dann tun Sie dies natürlich, aber ich würde mich nicht verprügeln.

1
Jon Hopkins

Ich denke, dass einer der Gründe, warum auskommentierter Code als Codegeruch angesehen wird, darin besteht, dass er entweder darauf hinweist, dass der Programmierer, der ihn dort abgelegt hat, seine Quellcodeverwaltung nicht versteht oder dass er keinen verwendet. Beides wirft weitere Zweifel an vielen anderen Dingen auf, die sie ebenfalls tun.

Wenn Sie einen legitimen Grund dafür haben nd hinterlassen Sie eine Erklärung dafür, warum es ein legitimer Grund ist, wo es gefunden werden kann, dass es Ihnen wahrscheinlich gut geht. Die meisten Dinge, die allgemein als schlechte Nachrichten angesehen werden, können auch ein nützliches Werkzeug in den richtigen Händen sein. Das Problem ist, dass diese Hände seltener sind als Menschen, die glauben, sie zu haben.

0
glenatron

Es ist hilfreich, einen Überblick über die Funktionsweise der Programmierer zu dieser Zeit zu geben. Aber in diesen Tagen der allgegenwärtigen Quellcodeverwaltung gibt es keinen Grund, es endgültig zu belassen - die vorherigen Versionen enthalten den älteren Code, falls Sie jemals darauf verweisen müssen.

0
5arx

Ich glaube nicht, dass es hier Absolutes gibt. Ich lasse manchmal auskommentierten Code, wenn es nur ein kleiner Ausschnitt ist, besonders wenn es eine vernünftige Chance gibt, dass ich ihn bald wieder auskommentieren werde. Grundsätzlich lasse ich diese Schnipsel, solange sie die Lesbarkeit des eigentlichen Codes nicht beeinträchtigen und sich nicht überall vermehren.

Was ich absolut ablehne, sind vollständige Methoden des auskommentierten Codes. Ja, ich habe die schon mal gesehen: WTF. Sie können sich im Himmel der Quellenrevision ausruhen ;-)

0
Andres F.