Laden...

Wie mit altem, auskommentierten Sourcecode umgehen?

Erstellt von HeikoAdams vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.406 Views
HeikoAdams Themenstarter:in
62 Beiträge seit 2017
vor 6 Jahren
Wie mit altem, auskommentierten Sourcecode umgehen?

Hallo,
ich hatte gerade eine kleine Grundsatz-Diskussion mit einem Kollegen. Grund war, dass das Programm das hier intern eingesetzt wird voll von teilweis seit Jahren auskommentiertem Code ist.

Ich war der Meinung, das der weg kann, weil die Sourcen eh im git liegen und Code der auskommentiert ist so gut wie immer weg kann.

Er (Webdesigner) war der Meinung, ich sollte den Code stehen lassen, da man ja nie weiß, ob er irgendwann nochmal benötigt wird.

Ich hab ihn dann gefragt, ob er auch Pizzastücke wochenlang im Kühlschrank lagert, weil er sie ja eventuell noch mal essen will 😁

Wie ist Eure Meinung zu dem Thema?

Wer ordentlichen Code schreibt, lebt entspannter 8)

3.003 Beiträge seit 2006
vor 6 Jahren

Ich war der Meinung, das der weg kann, weil die Sourcen eh im git liegen und Code der auskommentiert ist so gut wie immer weg kann.

This. Kenne aber auch so ein paar Messies, die am liebsten nie was löschen würden, sondern nur auskommentieren (und natürlich noch Kommentare dazu, WARUM etwas auskommentiert wurde).

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

D
985 Beiträge seit 2014
vor 6 Jahren

Ist wohl eher eine Glaubensfrage, aber jede Hinterlassenschaft birgt auch eine Botschaft und wenn die präsent ist springt die auch ins Auge.

Liegen die alten Pizza-Stücke noch im Kühlschrank, dann weiß ich, welche ich schon mal probiert habe und anhand der Menge der Hinterlassenschaft könnte ich ableiten, ob mir diese geschmeckt hat.

Noch sinnvoller wäre ein Hinweis, warum da noch was herumliegt (hat nicht geschmeckt oder war voll lecker aber ich war leider schon satt).

Im Source geht das ja noch einfacher mit den Kommentaren. Mit Regions kann man die Teile auch ausblenden, wenn die ansonsten stören.

Es ist also eher der generelle Umgang mit dem Auskommentieren und wie sinnvoll es ist den alten Code noch stehen zu lassen (haben wir so schon mal versucht, war aber doof weil und nicht mehr so machen).

Als Alternative kann man aber auch ein internes Wiki aufbauen mit einer DoAvoidThis Abteilung, wo man diese Erkenntnisse sammelt und entsprechend untereinander verlinkt (Source->Wiki, Wiki->Git-Commit)

16.806 Beiträge seit 2008
vor 6 Jahren

Auskommentierter Code erhöht den Aufwand von Code Reviews.

Auskommentierter Code ist für die faulen Entwickler, die meinen, dass sie einen Quick Rollback benötigen, falls sie was verhunzen.
Spätestens beim Merge in den master gehört es aber weg.

Er (Webdesigner) war der Meinung, ich sollte den Code stehen lassen, da man ja nie weiß, ob er irgendwann nochmal benötigt wird.

Prinzipiell eine falsche Argumentation.
Sicherlich gibt es gewisse Ausnahmen, die ein Stehenlassen rechtfertigen könnten, aber "wer weiß, vielleicht brauchen wir das ja nochmal" widerspricht jeglicher Vorgehensweise von Software Entwicklung.
Zudem: auch das erfüllt eben ein Quellcodeverwaltungssystem.

C# : I hate commented out code

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo HeikoAdams,

eh im git liegen

Genau deshalb soll das auch raus. Sollte es doch wieder reinmüssen, so ist über den Log (der auch pro Datei geht), Blame, etc. ja leicht zu finden und wiederherzustellen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

C
2.121 Beiträge seit 2010
vor 6 Jahren

Ich bin auch der Meinung Codeleichen gehören weg. Wenn man etwas aus welchem Grund auch immer für die Nachwelt festhalten will, gehört es kommentiert so dass jeder weiß warum das da steht. Selbst das sollte aber einen Grund haben, wer programmieren kann weiß auch wie er sich etwas selbst macht wenn es denn wirklich mal nötig sein sollte.
Einfach auskommentieren lässt mehr Fragen offen als es hilft.

2.207 Beiträge seit 2011
vor 6 Jahren

Hallo zusammen,

bin ebenfalls der Meinung, dass sowas raus sollte, weil es sowieso in der SourceCode-Verwaltung abgelegt ist. Man kann ja immer wieder zurück.

Das Problem mit auskommentiertem Code wurde auch schon angesprochen: Ein anderer Entwickler, oder ich selber, habe keine Ahnung mehr, warum ich den Code auskommentiert habe. Das Einkommentieren bringt ab einem gewissen Zeitpunkt auch nichts mehr, wenn anderweitig eine (bessere) Lösung implementiert wurde. Dann werden Dinge eventuell doppelt gemacht oder es knallt komplett. Am Ende vom Tag bringt es mehr Verwirrung als es klärt.

Auch Kommentare dazu sind heikel. Irgendwann schreibt einer "Bitte stehen lassen", was auch keinem hilft.

Also raus damit. Sourcecode-Verwaltungen sind so schlau, dass man da gut zurückgehen kann.

Gruss

Coffeebean

B
357 Beiträge seit 2010
vor 6 Jahren

Nachdem auskommentierter Code bei unserem Hauptprodukt fast im Umfang von laufendem Code vorhanden war, haben wir nach der Umstellung von SourceSafe auf TFS beschlossen, dass das Zeug in den Initial-Checkin zwar reinkommt, beim nächsten Checkin aber rigoros rausfliegt. Der Prozess ist nach wie vor im Gange, da es halt ein Projekt von ~2 Millionen LOC ist, aber die Richtlinie ist eindeutig: "Brauchen wir vielleicht nochmal" -> in den Lokus damit.

Es gibt lediglich eine Ausnahme, die für uns halt so eine Debug-Krücke ist. In den Unmengen C++-Code finden sich manchmal auskommentierte Blöcke, die bei Problemen wieder reingenommen werden beim Debuggen. Ja, kann man auch mal auf #ifdef umstellen, hatte bisher aber keiner Zeit dazu. Ist halt noch aus den 90ern übrig und wird sicher irgendwann in besseren Code gegossen, aber bis dahin ist es die (einzig)erlaubte Ausnahme von der Löschen-Regel.

HeikoAdams Themenstarter:in
62 Beiträge seit 2017
vor 6 Jahren

Nachdem auskommentierter Code bei unserem Hauptprodukt fast im Umfang von laufendem Code vorhanden war, haben wir nach der Umstellung von SourceSafe auf TFS beschlossen, dass das Zeug in den Initial-Checkin zwar reinkommt, beim nächsten Checkin aber rigoros rausfliegt.

So extrem ist es hier zwar noch nicht, aber es gibt schon auch einige Klassen, wo man sich durch seitenlange Kommentare scrollen "darf". Aber die werden jetzt auch von mir entsorgt, sobald sie mir vor die Flinte äh Maus kommen 😉

Wer ordentlichen Code schreibt, lebt entspannter 8)