it-swarm.com.de

Warum ist es falsch, Code zu kommentieren und dann schrittweise zu entfernen, um zu verfolgen, was ich bereits getan habe und was noch zu tun ist?

Immer wenn ich herausfinde, dass ein großer Teil meines Codes geändert werden muss, entweder weil er falsch ist oder weil er an wichtige architektonische Änderungen angepasst werden muss, die aus anderen Gründen erforderlich sind, mache ich Folgendes:

  1. Ich kommentiere den gesamten Code aus, von dem ich vermute, dass ich ihn ändern muss. Ich behandle den auskommentierten Code als eine Art meiner TODO-Liste.
  2. Ich überprüfe nach und nach den auskommentierten Code und kommentiere Teile dieses Codes aus oder kopiere sie an anderer Stelle und bearbeite sie dann nach Bedarf oder schreibe Teile dieses Codes von Grund auf neu, wobei ich den auskommentierten Code als Referenz betrachte. Immer wenn ich denke, dass ich mit einem Teil des auskommentierten Codes fertig bin, entferne ich ihn.
  3. Ich mache so weiter, bis ich keinen auskommentierten Code mehr sehe.

Ich sollte beachten, dass ich dies hauptsächlich für das persönliche Projekt mache, das ich alleine entwickle.

Mir wurde jedoch gesagt, dass ich damit aufhören sollte. Mir wurde gesagt, dass ich stattdessen git verwenden sollte, indem ich mich auf alte Commits beziehe, um alten Code zu sehen, anstatt auskommentierten Code zu belassen. Mir wurde gesagt:

Das Auskommentieren von Code ist eine schlechte Angewohnheit, die ausgelöscht werden sollte. Ihnen fehlt die Erfahrung, deshalb verstehen Sie das nicht. Wenn Sie in einigen Jahren den Code einer anderen Person sehen, die gerne Code auskommentiert, werden Sie selbst anfangen, diese Person anzuschimpfen. Immer wenn ich auskommentierten Code sehe, entferne ich ihn vollständig, ohne ihn überhaupt anzusehen, da dieser Code normalerweise völlig wertlos ist. Sie werden sicherlich die Nachteile des Auskommentierens von Code in kleinen Ein-Personen-Projekten nicht erkennen. Aber wenn Sie einen Job finden und diese Gewohnheit dort behalten, wird es eine Schande sein.

Darf ich fragen, was sind diese Nachteile von dem, was ich tue, was ich jetzt nicht sehe?

Ich muss sagen, dass ich nicht wirklich daran interessiert bin, nur Git zu verwenden, um früheren Code zu sehen. Wie gesagt, ich behandle das Auskommentieren von Code als eine Art Aufgabenliste; Während git mir zeigt, wie der Code früher aussah, wird es mir nicht klar zeigen, welche Teile des Codes noch überprüft werden müssen und welche bereits fertig sind. Ich befürchte, ich könnte einen Teil des Codes verpassen und Fehler einführen.

Der Vollständigkeit halber sollte ich hinzufügen, dass die Person, die ich zitiere, ein erfahrener Entwickler und ein Fan von Onkel Bobs "Clean Code" ist - und Onkel Bob hat das Auskommentieren von Code in seinem Buch scharf kritisiert.

22
gaazkam

Wenn Sie letztendlich den gesamten auskommentierten Code entfernen, sehe ich kein wirkliches Problem damit. Das Belassen von kommentiertem Code in Ihrer Codebasis ist eine schlechte Praxis, aber das tun Sie nicht, wenn Sie alles durcharbeiten und beseitigen. Ich vermute, dass die Person, mit der Sie sprechen, den von Ihnen verwendeten Prozess entweder nicht versteht oder dogmatisch ist.

In Wirklichkeit ist kommentierter Code harmlos. Das Problem ist, dass es chaotisch ist und das Lesen erschwert. Es gibt weitaus schlimmere Sünden, aber es ist sehr einfach, sie zu beseitigen. Als Person, die den Code auskommentiert hat, können Sie am besten feststellen, dass er vollständig entfernt werden kann.

Viele IDEs und Code-Editoren verstehen eine Art 'TODO'-Syntax in Kommentaren. Dies ist eine alternative Methode, um zu markieren, was geändert werden muss. Vielleicht möchten Sie dies berücksichtigen, da es ein wenig mehr Informationen darüber gibt, was Sie gedacht haben, als Sie es markiert haben.

Am Ende des Tages tun Sie die Dinge so, dass Sie das beste Ergebnis erzielen. Selbst wenn dies ein Teamprojekt wäre, belasten Sie niemanden, solange Sie den gesamten kommentierten Code entfernen.

29
JimmyJames

Darf ich fragen, was sind diese Nachteile von dem, was ich tue, was ich jetzt nicht sehe?

Wahrscheinlich keine, wenn Sie alleine arbeiten und keine Versionskontrolle verwenden und der Meinung sind, dass es in Ordnung ist, dies auf diese Weise zu tun.

In der Tat spielt es ohne Versionskontrolle keine Rolle, was Sie zu irgendeinem Zeitpunkt in "Zeit" tun, da der Code immer den Status hat, in dem die aktuelle Datei wie im Betriebssystem "gespeichert" wird.

Wenn Sie die Versionskontrolle verwenden und eine Menge Kommentare als "Aufgabenliste" haben und einige korrigieren und den Kommentar entfernen, dann wiederholen, dann wiederholen usw. ... dann haben Sie den Code "work in progress" und die Kommentare gespeichert in Ihrem Revisionsverlauf. Dies ist kein Problem, wenn Sie später nie mehr zu einem anderen Commit oder sogar zu einem "Cherry Pick" zurückkehren müssen (hier nehmen Sie beispielsweise bestimmte Commits und ziehen sie in einen anderen Zweig, um sie zu verwenden). Aber sonst könnte es ein Problem sein.

Dies kann wohl mit "Schnappschüssen" der Festplatten-Software verglichen werden, wie sie Windows hatte (das Wiederherstellen-Ding). Wenn ein Snapshot mit einem Virus erstellt wird, töten Sie den Virus, müssen ihn aber später zurücksetzen. Sie können dann zu einem Punkt zurückkehren, an dem der Virus wieder vorhanden ist.

Dieser Ansatz ist auch wahrscheinlich ein Problem, wenn Sie die Versionskontrolle verwenden nd arbeiten mit anderen Entwicklern, da sie dann Ihre Aufgabenliste sehen müssen das hat keinen Sinn für sie. Tatsächlich ist es nur Unordnung, die sie ignorieren und umgehen müssen. In unseren Teams entfernen wir immer alle Kommentare wie alten Code oder "Notizen". Es sei denn, sie sind nützlich - dies ist jedoch sehr selten, da wir eine Dokumentation zur Funktionsweise und eine Software zur Verfolgung der zu erledigenden Aufgaben (auch bekannt als todo) haben.

Wenn Sie an einem größeren Projekt arbeiten, arbeiten Sie häufig zusammen und legen fest und pushen häufig. Daher ist es möglich, dass der Zweig, an dem sie arbeiten, Ihre TODO-Liste enthält, wenn sie Ihren Zweig mit ihrem zusammengeführt haben. Dann geht Ihre TODO-Liste alle an: D.

Zusammenfassend lässt sich sagen, dass wenn Sie nicht alleine arbeiten und insbesondere die Versionskontrolle verwenden, dies den Verlauf überfüllt und für andere Entwickler unübersichtlich sein kann.

Und dies ist in mancher Hinsicht eine persönliche Sache, aber die Verwendung einer Codebasis als "Aufgabenliste" ist nicht wirklich ideal. Eines Tages könnten Sie versehentlich etwas zurücklassen oder vergessen, es zu kommentieren oder versehentlich zu kommentieren.


Wie bei vielen Ansätzen in Bezug auf Architektur, Codierung und die Art und Weise, wie Sie persönlich oder Ihr Team arbeiten, kann jedes Szenario etwas anderes erfordern. Berücksichtigen Sie also die genannten Nachteile und die Vorteile der Versionskontrolle und entscheiden Sie, ob sie für Sie funktioniert.

6
James

Es hört sich so an, als wäre Ihr Rezensent ein wenig dogmatisch. Ich bin mir nicht sicher, ob es PC ist, jemanden für das Auskommentieren von Code zu beschwören ;-) oder sogar hilfreich ;-)

Aber im Ernst, ich denke, Ihr Rezensent IS richtig, dass Sie ernsthaft in Betracht ziehen sollten, git (oder ein anderes Quellcodeverwaltungssystem, aber git ist eine vernünftige Wahl) zu verwenden.

Dies kann einige Ihrer Anforderungen zum Auskommentieren von Code verringern.

Aber eine TODO-Liste im Code zu haben (ob Listen mit Aufzählungszeichen oder alter Code) - ist meiner Meinung nach durchaus vernünftig. Aber vielleicht möchten Sie ein wenig darüber nachdenken, wie Sie es tun. Zum einen schlage ich vor, an jemanden zu denken, der Ihren Code liest. Dass jemand anderes Sie sein könnte, ein Jahr nachdem Sie ein Projekt fallen lassen und wieder beitreten. Oder es könnte jemand anderes sein. Es ist etwas verwirrend, nur auf auskommentierten Code zu stoßen. Vielleicht so etwas wie:

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

Persönlich neige ich eher zu so etwas:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

und ich kann gerne 'Code-Schnipsel' aus altem Code als hilfreich einwerfen.

Git zu benutzen ist schwer (leider). Es wird eine Weile dauern, bis Sie es gelernt haben, und es scheint, als wäre es nicht Teil dessen, was Sie erreichen wollen. Aber wenn Sie sinnvoll programmieren wollen, müssen Sie lernen, dies als Teil eines Teams zu tun und mit einem Team zu kommunizieren, und Git ist genau das, was heutzutage gemacht wird. Und sobald Sie es verwendet haben, werden Sie feststellen, dass es ein SEHR hilfreiches Werkzeug/eine SEHR hilfreiche Krücke ist, die Ihre Softwareentwicklung erleichtert.

Viel Glück!

4
Lewis Pringle

Es gibt viele Gründe, Code zu kommentieren: -

  • Es ist noch nicht richtig und Sie werden es auskommentieren, wenn es fertig ist.
  • Sie kommentieren es vorübergehend aus, um das Verhalten beim Debuggen zu ändern.
  • Sie sind sich nicht sicher, ob der Code benötigt wird, möchten ihn jedoch erst löschen, wenn Sie weitere Tests durchgeführt haben.
  • Der Code wird für einige Versionen der Software benötigt, jedoch nicht für diese.
  • Der Code ist veraltet, aber das Schreiben hat ewig gedauert und Sie sind emotional daran gebunden. Außerdem könnte es eines Tages nützlich sein.

Das Problem tritt auf, wenn Sie den Code ins Bett legen und einige Jahre später darauf zurückkommen, um einige Wartungsarbeiten durchzuführen. Sie finden die Codebasis mit auskommentiertem Code übersät. Es wird nicht mehr klar sein, warum irgendetwas davon da ist, und es ist jetzt nur noch Unordnung.

Wenn Sie ein halbwegs anständiges Tool zur Versionskontrolle verwenden, können Sie mutig jeden Code löschen, den Sie nicht mehr benötigen. Dabei können Sie sicher sein, dass das Versionskontrollsystem ihn noch gespeichert hat. Ein Dateidifferenz zwischen den Versionen zeigt an, was gelöscht wurde. Sobald Sie die Versionskontrolle implementiert haben, müssen Sie nur noch temporäre Inhalte auskommentieren. Wenn Sie jemals auskommentierten Code in Dateien finden, an denen Sie gerade nicht arbeiten, können Sie ihn einfach löschen.

2
Simon B

Ich werde nicht wiederholen, warum Sie die Quellcodeverwaltung auch für Ein-Personen-Projekte verwenden sollten, da es viele andere Ressourcen gibt, die Sie dazu auffordern. Ein wesentlicher Nachteil Ihres aktuellen Ansatzes ist jedoch, dass Sie Code, wenn Sie ihn auskommentieren, vor Ihrem IDE (wenn Sie kein IDE verwenden) verbergen) Sie sollten es wahrscheinlich in Betracht ziehen).

Wenn Sie beispielsweise eine Methode oder Klasse umbenennen oder die Anzahl der Parameter ändern möchten, die eine Methode benötigt, sollte Ihre IDE] eine Refactor-Option haben, um alle entsprechenden Referenzen und zu finden Aktualisieren Sie sie entsprechend - aber es wird wahrscheinlich nicht in Kommentaren gesucht.

Anstatt zu erraten, wo Sie Änderungen vornehmen müssen, nehmen Sie sie einfach vor und lassen Sie sich von Ihrem IDE] mitteilen, wo Ihre Änderungen zu einem Bruch geführt haben. Sie können den Code dann chirurgischer auskommentieren. und hoffentlich für einen kürzeren Zeitraum, bevor Sie das Problem beheben.

2
Chris Cooper

Es ist schlecht und du solltest aufhören.

Der Grund besteht darin, dass versucht wird, eine große Menge an Refactoring auf einmal durchzuführen.

Wenn Sie große Codeabschnitte auskommentieren, ein wenig korrigieren und einchecken, haben Sie nicht funktionierenden Code eingecheckt. und eine ganze Menge auskommentierter Dinge, von denen andere annehmen, dass sie alt sind und ignoriert werden können

Wenn Sie nicht oft einchecken, häufen Sie Zusammenführungskonflikte an und zeichnen den schrittweisen Fortschritt nicht auf.

Sie müssen Ihre Arbeitspraxis so ändern, dass alles noch funktioniert, wenn Sie auf halbem Weg anhalten müssen.

Machen Sie kleine Schritte und checken Sie nach jedem ein:

  • eine Schnittstelle extrahieren
  • schreibe einen Test
  • eine Funktion umgestalten

Markieren Sie große Codestücke nicht als "Ihre", indem Sie sie auskommentieren und wegnehmen, um selbst daran zu arbeiten, bis sie vollständig sind oder Sie versagen.

Wenn Sie nachverfolgen müssen, was zu tun ist, verwenden Sie ein Taskboard wie Scrum oder Trello

1
Ewan