Sollte sich die Syntax zum Deaktivieren von Code von der von normalen Kommentaren unterscheiden?


8

Aus mehreren Gründen kommentiere ich während der Entwicklung manchmal Code aus. Da ich chaotisch bin und es manchmal eilig habe, schaffen es einige von ihnen zur Quellcodeverwaltung.

Ich benutze auch Kommentare, um Codeblöcke zu klären.

Zum Beispiel:

MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}

Obwohl es "funktioniert" und viele Leute es auf diese Weise tun, ärgert es mich, dass Sie auskommentierten Code nicht automatisch von "echten" Kommentaren unterscheiden können, die den Code verdeutlichen:

  • Es fügt Rauschen hinzu, wenn versucht wird, Code zu lesen
  • Sie können nicht nach auskommentiertem Code suchen, z. B. nach einem On-Commit-Hook in der Quellcodeverwaltung.

Einige Sprachen unterstützen mehrere einzeilige Kommentarstile - zum Beispiel in PHP, die Sie entweder verwenden können //oder #für einen einzeiligen Kommentar - und Entwickler können sich darauf einigen, einen dieser Stile für auskommentierten Code zu verwenden:

# return null; // TODO: dummy for now
return obj;

Andere Sprachen - wie C #, das ich heute verwende - haben einen Stil für einzeilige Kommentare (richtig? Ich wünschte, ich hätte mich geirrt). Ich habe auch Beispiele für das "Auskommentieren" von Code unter Verwendung von Compiler-Direktiven gesehen, was für große Codeblöcke großartig ist, aber für einzelne Zeilen ein wenig übertrieben, da für die Direktive zwei neue Zeilen erforderlich sind:

#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;

Sollte "deaktivierter Code" nicht eine eigene Syntax in den Sprachspezifikationen erhalten, da das Auskommentieren von Code in jeder (?) Sprache erfolgt? Sind die Vorteile (Trennung von Kommentaren / deaktiviertem Code, Editoren / Quellcodeverwaltung) gut genug und die Nachteile ("sollte sowieso nicht auskommentieren", kein funktionaler Teil einer Sprache, potenzielle IDE-Verzögerung (danke Thomas))))) )) Opfer wert?

Bearbeiten

Mir ist klar, dass das Beispiel, das ich verwendet habe, albern ist. Der Dummy-Code kann leicht entfernt werden, da er durch den tatsächlichen Code ersetzt wird.


Ich sehe darin nichts allzu Falsches - das Auskommentieren und Auskommentieren kleiner Codeblöcke ist manchmal eine nützliche Taktik zum Debuggen sehr spezifischer Fehler in großen Legacy-Codebasen. Ich finde, dies hilft mir, Probleme einzugrenzen (zusätzlich zur Verwendung eines geeigneten Debuggers natürlich). Ich habe nichts dagegen , eine spezielle Art von Kommentar zu sehen, vielleicht /# ... #/das wäre anders in den IDE markiert (für visuelle Hinweise) und vielleicht einen Compiler generieren Warnung , die dann in der Nightly Build gefangen und berichtet würde, wenn jemand sich solche Änderungen wieder überprüfen in die Quellcodeverwaltung.
FrustratedWithFormsDesigner

Antworten:


18

Zunächst gibt es in Ihrem Beispiel "TODO" -Kommentare. Diese Arten von Kommentaren sind in gewisser Weise besonders, da sie von IDEs (zumindest Eclipse und Visual Studio) als Markierung für "Aufgaben" erkannt werden. Aber ich bin mir sicher, dass Sie das wissen, da Sie thme verwenden, und ich nehme an, dass Sie sich nicht auf sie beziehen, wenn Sie den Begriff "deaktivierter Code" verwenden.

Was den deaktivierten Code selbst betrifft, ist meine Meinung, dass er den Code verschmutzt. Ich benutze einen anderen Mechanismus, um zu verfolgen, was vorher da war: das Quell-Repository . Außer wenn ich mich in einem Code / Test / Code / Test ... -Modus befinde, kommentiere ich nicht verwendeten Code nicht, sondern entferne ihn. Und wenn es so ist, ist das Kommentieren von X-Zeilen nur eine Frage einer Tastenkombination.

Bearbeiten: Also ja, ich habe vergessen, Ihre explizite Frage zu beantworten. Ich denke, dass es nicht nützlich ist, spezielle Kommentare für deaktivierten Code zu haben. Wenn Sie den Code wirklich behalten möchten, aber "Nicht verwenden" sagen, können Sie ihn immer als @deprecated markieren, aber das war nicht der Punkt Ihrer Frage.


Früher habe ich schmutzigen Code geschrieben und war stolz darauf, "Hacks" und schnelle Korrekturen zu verwenden. Heutzutage schätze ich die Struktur - vielleicht kann ich mich auch daran gewöhnen.
Deltreme

2
TLDR; Verwenden Sie die Quellcodeverwaltung.
Chris

1
@deltreme Ich gebe zu, dass ich das Gleiche getan habe (zeigen Sie, wie ich den Code "verbessert" habe!), bevor ich ernsthaft anfing, ein Quell-Repository in einer professionellen Umgebung zu verwenden. Seitdem schätze ich es, die wenigsten Codezeilen lesen zu müssen, die ich jeden Tag muss.
Jalayn

Verwenden Sie die Quellcodeverwaltung und lesen Sie die Unterschiede, bevor Sie sie festschreiben.
Onkel Zeiv

1
Leider lag der Fokus der Antworten darauf, wie man deaktivierten Code nicht festschreibt, nicht darauf, wie albern der Begriff "Auskommentieren" wirklich ist. Ich habe eher eine Mischung erwartet. Akzeptiere diese Antwort, als ich um eine Meinung gebeten habe und du hast die Community, die dich unterstützt: P
deltreme

5

Aus mehreren Gründen kommentiere ich während der Entwicklung manchmal Code aus. Da ich chaotisch bin und es manchmal eilig habe, schaffen es einige von ihnen zur Quellcodeverwaltung.

Ich denke, das ist die Wurzel des Problems. Chaotisch und gehetzt zu sein, wird nur Probleme mit sich bringen. Der erste Schritt sollte darin bestehen, herauszufinden, warum Ihre Entwicklung beschleunigt und nicht gut kontrolliert wird, und nicht zu versuchen, auskommentierten Code zu finden.

Sollte "deaktivierter Code" nicht eine eigene Syntax in den Sprachspezifikationen erhalten, da das Auskommentieren von Code in jeder (?) Sprache erfolgt? Sind die Vorteile (Trennung von Kommentaren / deaktiviertem Code, Editoren / Quellcodeverwaltung) gut genug und die Nachteile ("sollte sowieso nicht auskommentieren", kein funktionaler Teil einer Sprache) es wert, geopfert zu werden?

Das glaube ich nicht. Auskommentierter Code ist eine schlechte Praxis und ich denke nicht, dass Sprachen jemanden dazu ermutigen sollten, ihn zu verwenden. Ja, die Leute machen es und ich habe es gesehen, aber ich weigere mich, meinen Code einzuchecken, der auskommentiert ist. Menschen die Möglichkeit zu geben, unbenutzten, alten Code einfach zu verwalten, geht über den Rahmen einer Sprache hinaus und gehört in den Bereich der Versionskontrolle.

Ich mache mir auch Sorgen um technische Einschränkungen. Damit dies funktioniert, müssen Sie entweder Kommentare analysieren und feststellen, ob sie als Quelle oder Text auskommentiert sind, oder der Sprache ein neues Token hinzufügen. Abhängig von der aktuellen Komplexität der Sprache bin ich mir nicht ganz sicher, welche Auswirkungen dies auf die Kompilierung haben würde (Feststellung, ob eine Zeile gültiger zu kompilierender Code ist oder nicht). Außerdem würden die Benutzer dann erwarten, dass IDEs dies in Echtzeit verwalten (besteht ein Zusammenhang zwischen der Komplexität der Syntax einer Sprache und der Reaktionsfähigkeit der IDE beim Auffinden und Hervorheben verschiedener Konstrukte und Fehler).


Ich versuche, mein Chaos und meine Eile in den Griff zu bekommen, und ich stimme vollkommen zu, dass hier alles beginnt. Derzeit passiert dies jedoch und ich bin mir sicher, dass jemand anderes meinen Platz einnehmen wird, sobald ich keinen Code mehr auskommentieren kann. Vielleicht nörgele ich nur. Am Ende ist es keine so große Sache. Was die technischen Aspekte betrifft: IDEs können sie sogar als reguläre Kommentare behandeln, eine Farbe verwenden oder sie ausblenden - viele IDEs unterstützen dies bereits für andere Syntaxelemente.
Deltreme

@deltreme Es ist mir egal, wie IDEs sie an der Oberfläche unterstützen würden. Wie würden IDEs sie auf eine Weise finden und verarbeiten, die korrekt ist und dennoch die Reaktionsfähigkeit beibehält? Das Hinzufügen von Token zu einer Sprache oder das Hinzufügen von Textverarbeitung kann das Parsen verlangsamen oder zu ungenauen Ergebnissen führen.
Thomas Owens

Ich hätte nicht gedacht, dass die Diskussion so verlaufen würde :) Und ich glaube nicht, dass das Hinzufügen eines weiteren Tokens (wie viele erkennt eine moderne IDE heutzutage?) Zu einem schlecht reagierenden Editor führen würde. Wenn Sie es bereits in der Forschungsphase dieses "Projekts" als potenzielle Bedrohung betrachten, hätten Sie eine Schätzung des prozentualen Leistungsverlusts? Angenommen, wir fügen ein Token hinzu und möchten eine Farbe dafür in einer IDE.
Deltreme

@deltreme Ich denke nicht, dass es für die meisten Projekte so viel Zeit bedeuten würde, aber in Bezug auf Zeitschöpfung / Wertschöpfung ist das Verhältnis sehr schlecht. Wenn Sie diese zusätzlichen paar Mikrosekunden zu Zehntausenden von Quelldateien hinzufügen mussten, haben Sie jedes Mal, wenn Sie eine Quelldatei analysieren, Millisekunden zu allem hinzugefügt, was jemals eine Quelldatei analysiert. Bei einer IDE ist dies normalerweise jedes Mal der Fall, wenn Sie speichern. Dies gilt auch für Ihre Post-Commit- und / oder täglichen Builds. Wenn Sie diese Millisekunden zusammensetzen, wird es sehr schnell in Minuten über die Lebensdauer eines Projekts messbar, mit einer Funktion umzugehen, die keinen Mehrwert bietet.
Thomas Owens

1
@deltreme Auf keinen Fall. Wenn Sie in Ihrem Projekt Code deaktiviert haben, der es in die Quellcodeverwaltung geschafft hat, machen Sie es falsch. Wenn ich eine Methode umschreibe, kann ich gelegentlich die alte Methode auskommentieren und erneut implementieren. Wenn ich jedoch sicher bin, dass der neue Code die Tests besteht und wie beabsichtigt funktioniert, entferne ich den deaktivierten Code und checke ihn ein Das Einchecken von deaktiviertem Code oder das Verlassen darauf in irgendeiner Weise ist ein Zeichen für größere Probleme im Projekt, die behoben werden müssen.
Thomas Owens

4

Selbst wenn es nur eine Kommentarsyntax in der Sprache gibt, die Sie verwenden, können Sie dennoch Ihre eigene Variante hinzufügen. Ich habe an Projekten gearbeitet, bei denen // eine deaktivierte Zeile und // - einen Kommentar angegeben haben. Es ist nicht so schön wie es eingebaut zu haben, aber die meisten IDEs wissen nicht, dass Sie die verschiedenen Syntaxen für verschiedene Zwecke verwendet haben. Daher funktioniert manchmal die alte Art des Augapfelns, um den Unterschied zu erkennen, am besten.


Wenn sich das Team diesem Geschmack widmet, wäre dies sicherlich eine gute Lösung. Es ist sogar "on-commit-hook" -fähig, und wenn Sie die zusätzlichen Zeichen für etwas vergessen, das als Kommentar gedacht ist, wird es auch alarmieren.
Deltreme

1

Im Gegensatz zu den Antworten antworte ich mit "JA, es sollte eine andere Syntax geben!"

Ich würde jeden Entwickler herausfordern zu sagen, dass er auch nur einen Tag lang codiert, ohne den Code zu kommentieren. Dies bedeutet nicht, dass man die Quellcodeverwaltung nicht kennt oder faul ist. Selbst wie Thomas Owens in seiner abweichenden Antwort sagt: " Außer wenn ich mich in einem Code / Test / Code / Test ... -Modus befinde, kommentiere ich keinen unbenutzten Code. "

Wie viel Zeit verbringst du im Code / Test / Code / Test-Modus? Für mich sind das mindestens 90% der Arbeit! Im Moment konvertiere ich ein großes OSX-Projekt in iOS. Der erste Schritt bestand darin, den gesamten Code zu deaktivieren, der kaputt ging, bis ich einen funktionierenden Stub hatte. In den nächsten Wochen werde ich den Code langsam auskommentieren und korrigieren, sobald er funktioniert.

Es gibt auch viele andere Fälle. Was ist, wenn Sie Beispielcode verwenden, in dem Sie häufig Anweisungen wie "Kommentar für Windows auskommentieren" oder "Diese Zeile für Apps nur für das iPhone auskommentieren" finden?

Ja, ich werde die ganze Zeit die Quellcodeverwaltung verwenden. Aber auch JA, ich würde es lieben, wenn es eine Möglichkeit gibt, deaktivierten Code von tatsächlichen Kommentaren zu unterscheiden.

Zusammenfassend: Jeder Programmierer, der sagt, dass er keine Kommentare zum Deaktivieren von Code verwendet, lügt. Codierung beinhaltet mehr als die polierten Dateien, die Sie für HEAD festlegen. Es gibt viele gültige Gründe für deaktivierten Code.

Ja, es wäre schön, wenn es eine Syntax (oder zumindest eine Konvention) gäbe, um echte Kommentare von deaktiviertem Code zu unterscheiden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.