Gibt es eine Methode, um informative Kommentare von auskommentiertem Code zu unterscheiden?

Während des Programmierens werden Sie einige Kommentare erhalten, die den Code erklären, und einige Kommentare, die den Code entfernen:

// A concise description 
const a = Boolean(obj);
//b = false;

Gibt es eine gute Methode, um schnell zu analysieren, welche welche ist?

Ich habe mit der Verwendung von /3en und /** */für beschreibende Kommentare herumgespielt.

Ich habe auch ein VSCode-Plugin verwendet, um //TODO:und hervorzuheben//FIXME:

Hierfür gibt es eine sehr einfache Lösung: Entfernen Sie den auskommentierten Code.

Tatsächlich gibt es nur zwei gute Gründe, um Code zu kommentieren: um etwas zu testen / zu reparieren oder um Code zu speichern, den Sie möglicherweise später verwenden. Wenn Sie etwas testen oder reparieren, entfernen Sie den auskommentierten Code, sobald Sie den Test oder die Fehlerbehebung abgeschlossen haben. Wenn Sie Code speichern, den Sie möglicherweise später verwenden, erstellen Sie ihn als erstklassigen Code und speichern Sie ihn an einem Ort, z.

Das Hinzufügen @ RobertHarvey die ausgezeichnete Antwort glaube ich , es nur einen legitimen Grund ist die ich je für das Speichern von kommentierten Code zur Quellcodeverwaltung gestoßen, auch nur vorübergehend: bei nicht offensichtlichen Ersatz - Code, der sollte jetzt nicht oder aus irgendeinem Grund nicht verwendet werden kann , . Selbst dann sollte der Großteil des Kommentars die Erklärung sein, nicht der Ersatzcode. Dies könnte ein Fehler oder eine Eigenschaft der Sprache sein, die noch nicht als stabil angesehen wird. Es könnte ungefähr so ​​aussehen:

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

In diesem Fall ist die Arbeit bereits erledigt, Sie können sie jedoch noch nicht nutzen. Wenn Sie sie löschen, muss sie später erneut entdeckt werden. Gleiches gilt für suboptimale Lösungen, die auf den ersten Blick überlegen erscheinen können, oder für bewusste Kompromisse mit ähnlichen Lösungen .

Achtung: Verunreinigen Sie Ihren Code nicht mit alternativen Lösungen. Jede Aufgabe kann auf unendlich viele verschiedene Arten erledigt werden, und es ist nicht wirtschaftlich, diesen Raum für jede Änderung über einen langen Zeitraum zu erkunden. Code Reviews können ein guter Ort sein, um solche fehlenden Kommentare zu entdecken, wenn Ihr Kollege eine Verbesserung vorschlägt, die Sie bereits als suboptimal erkannt haben.

Hmm, ich habe diese Frage etwas anders gelesen als Robert, der zu Recht behauptet, dass auskommentierter Code entfernt werden sollte.

Wenn Sie jedoch nach einer Konvention suchen, mit der Code zum späteren Entfernen markiert wird, ist einer meiner alten Favoriten:

//b = false; //TODO: remove

Einige IDE-Flag- //TODO:Kommentare oder können gelehrt werden. Wenn nicht, ist es normalerweise eine durchsuchbare Zeichenfolge. Befolgen Sie am besten die Konventionen Ihres Shops, da dies auf verschiedene Arten erfolgen kann. Jede Codebasis sollte dies auf eine Weise tun. Hält es durchsuchbar.

schnell analysieren was ist was?

Ohne diese Markierung erfolgt dies automatisch mit dem Compiler. Wenn das Entfernen des Kommentars zu kompiliertem Code führt, muss es sich um kommentierten Code handeln. Schreiben eines IDE-Plugins, das prüft, ob dies nicht schwierig ist. Aber es wird fehlerhaft kommentierten Code hinterlassen.

Aus diesem Grund ist es besser, auskommentierten Code einfach als Code zu markieren, sobald Sie ihn auskommentieren. Auf diese Weise können Sie zerstörungsfrei arbeiten, während Sie entscheiden, ob Sie es wirklich wollen. Da wir alle unterbrochen werden und etwas vergesslich sind, wundern Sie sich nicht, wenn in diesem Zustand einige Zeilen eingecheckt werden. Wenn sie es tun, ist es schön, dass sie zumindest deutlich gekennzeichnet und durchsuchbar sind. Tastaturmakros haben mir in der Vergangenheit dabei geholfen. Es ist schwer, in der Mitte davon unterbrochen zu werden, wenn Sie es mit einem einzigen Tastendruck tun können.

Sie können dies so weit führen, dass Sie die Marke in Ihren kontinuierlichen Integrationstests verankern. Hoppla, ich versuche erneut, bei hervorragenden TODOs einzuchecken.

Ich verwende Präprozessor-Direktiven, um Code zu entfernen, keine Kommentare:

//comment
active_code();
#if FALSE
inactive_code();
#endif

Das macht das Suchen sehr einfach und mein Syntax-Textmarker behandelt es als Kommentar. Ich kann es sogar zu einer einzigen Zeile zusammenfassen:#if FALSE(...)

Sie können diese Idee erweitern, um mehrere Optionen zu haben:

#if OPTION == 0
code_for_option_0();
#elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif

Und Fehlerüberprüfung zur Kompilierungszeit:

#if FOO >= 5
#error FOO should be less than 5!
#endif

Natürlich wollen Sie nicht über Bord gehen, oder es wird schwierig zu sagen, was tatsächlich kompiliert wird und was nicht. Aber Sie haben die Idee, und es ist sowieso das gleiche Problem wie für kommentierten Code ... solange Sie ihn nur statisch verwenden. Wenn Ihre Bedingungen dynamisch sind, ist es schlimmer.

Um herauszufinden, welche Codebasis welche ist, die dieses Problem überhaupt nicht berücksichtigt hat, gibt es meines Erachtens keine universelle Lösung. Sie müssen selbst Muster finden und wahrscheinlich einen regulären Ausdruck codieren, um sie zu finden.

Ich stimme der Antwort zu, dass alter Code entfernt und nicht auskommentiert werden sollte, obwohl ich in den wenigen Fällen, in denen auskommentierter Code benötigt wird, eine Konvention eingehalten habe.

(Meine Basis ist C #, aber dies kann auf jede C-Syntax-Sprache angewendet werden, zB Java)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}

Ich interpretiere die Frage immer noch anders und denke, Sie möchten auskommentierten Code finden.

C-Code muss Semikolons enthalten, während in Kommentaren Semikolons unwahrscheinlich sind. Für einzeiligen auskommentierten Code können Sie also diesen regulären Ausdruck verwenden:

\s*\/\/[\s\S]*;

Bei mehrzeiligem auskommentiertem Code könnte es sein

\/\*[^\;]*;[^\;]*\*\/

Hinweis: Visual Studio ist etwas eigenartig in Bezug auf Zeilenumbrüche in regulären Ausdrücken. Sie zählen nicht als Leerzeichen. Sie müssen ein explizites \ n angeben.

Wenn Sie einen Editor mit einem im Hintergrund laufenden Compiler (wie Xcode und Clang) verwenden, können Sie einfach versuchen, den Text des Kommentars zu kompilieren. Zum Beispiel gibt "eine kurze Beschreibung" Fehler aus, "b = false;" nicht. Sie könnten dann eine andere Syntaxhervorhebung verwenden.

Eine einfachere Methode wäre ein IDE-Plugin, das einige Heuristiken verwendet, z. B. mehrere Wörter in einer Reihe, außer Schlüsselwörtern, die auf Kommentare verweisen, geschweifte Klammern, die auf Code verweisen usw.

Andere Antworten haben Variationen des Themas "Code nicht auskommentieren" behandelt. Aber manchmal möchten Sie es trotzdem als Referenz haben.

Wenn Sie den Code wirklich brauchen, um in der Nähe zu bleiben, ist es eine bessere Lösung, den Code mit "#if 0 ... #endif" zu umgeben, idealerweise mit einem Kommentar, aus dem hervorgeht, warum. Dies ist die empfohlene Strategie aus verschiedenen Codierungsstandards, einschließlich MISRA.

Zumindest für mich einfach - und in C / C ++. Die Kommentare in / * * / sind informativ. Testcode, der vorübergehend entfernt wird, wird mit führendem // auskommentiert.

Und es gibt gute Gründe, Testcode in der Datei zu belassen, aber auskommentiert, zumindest in der Art von Arbeit, die ich mache. Früher oder später wird jemand eine Änderung wünschen, die diesen Code benötigt. Das Aufheben des Kommentars für einen Block erfordert einen Editorbefehl, ebenso wie das erneute Kommentieren, wenn Sie fertig sind.