Einchecken von "auskommentiertem" Code [geschlossen]

Ok, hier ist etwas, das bei meinem aktuellen Job zu Reibereien geführt hat, und ich habe es wirklich nicht erwartet. Die interne Softwareentwicklung ist hier ein neues Konzept, und ich habe einen ersten Entwurf einiger Codierungsrichtlinien erstellt.

Ich habe vorgeschlagen, dass "auskommentierter" Code niemals in das Repository eingecheckt werden sollte. Der Grund, warum ich dies angegeben habe, ist, dass das Repository einen vollständigen Verlauf der Dateien verwaltet. Wenn Sie den Funktionscode entfernen, entfernen Sie ihn vollständig. Das Repository speichert Ihre Änderungen, sodass Sie leicht sehen können, was geändert wurde.

Dies hat zu Reibereien geführt, da ein anderer Entwickler der Ansicht ist, dass dieser Weg zu restriktiv ist. Dieser Entwickler möchte in der Lage sein, Code zu kommentieren, an dem er arbeitet, der jedoch unvollständig ist. Dieser Code wäre dann noch nie eingecheckt und dann nirgendwo gespeichert worden. Wir werden TFS verwenden, daher schlug ich vor, dass das Zurückstellen der Änderungen die richtigste Lösung wäre. Es wurde jedoch nicht akzeptiert, da er Teiländerungen einchecken möchte, die möglicherweise bereitgestellt werden oder nicht.

Wir möchten irgendwann einen Punkt erreichen, an dem wir die kontinuierliche Integration voll ausnutzen und automatisch auf einem Entwicklungswebserver bereitstellen. Derzeit gibt es keine Entwicklungsversion von Webservern oder Datenbankservern, aber das wird bald geändert.

Wie auch immer, was denkst du? Glauben Sie, dass "auskommentierter" Code nützlich ist, um ihn im Repository zu haben?

Ich bin sehr daran interessiert, von anderen zu diesem Thema zu hören.

Bearbeiten: Aus Gründen der Übersichtlichkeit verwenden wir keine privaten Zweige. Wenn wir das tun würden, würde ich sagen, mach was du willst mit deiner privaten Filiale, aber füge niemals auskommentierten Code mit der Amtsleitung oder einer gemeinsam genutzten Filiale zusammen.

Bearbeiten: Es gibt keinen gültigen Grund, warum wir keine privaten oder Zweige pro Benutzer verwenden. Es ist kein Konzept, mit dem ich nicht einverstanden bin. Wir haben es einfach noch nicht so eingerichtet. Vielleicht ist das der mögliche Mittelweg. Im Moment verwenden wir TFS-Regale.

Es mag andere mit unterschiedlichen Erfahrungen geben, aber bei mir ist das Einchecken von halbfertigem Code eine schreckliche Idee, Punkt.

Hier sind die Prinzipien, die ich gelernt habe und die ich zu befolgen versuche:

• Checken Sie häufig ein - mindestens einmal, vorzugsweise jedoch mehrmals täglich
• Checken Sie nur die vollständige Funktionalität ein
• Wenn der erste und der zweite Konflikt (z. B. dauert es mehr als einen Tag, bis die Funktionalität funktioniert), ist die Aufgabe zu groß - teilen Sie sie in kleinere abschließbare Aufgaben auf.

Das heisst:

• Auskommentierter Code sollte niemals eingecheckt werden, da er nicht funktioniert
• Das Kommentieren ist keine gültige Archivierungsstrategie. Unabhängig davon, ob es sich um noch ausstehenden Code handelt oder um Code, der in den Ruhestand versetzt wird, macht das Kommentieren und Einchecken keinen Sinn.

Also zusammenfassend NEIN! Wenn der Code nicht bereit ist, mit der nächsten Stufe fortzufahren (je nachdem, was für Sie bestimmt ist: IntTest / QA / UAT / PreProd / Prod), sollte er nicht an einen Trunk- oder Multi-Developer-Zweig gebunden werden. Zeitraum.

Bearbeiten: Nachdem ich die anderen Antworten und Kommentare gelesen habe, füge ich hinzu, dass ich es nicht unbedingt für eine gute Idee halte , kommentierten Code zu verbieten (nicht sicher, wie Sie das überhaupt durchsetzen würden). Was ich sagen werde, ist, dass Sie alle in Ihrem Team dazu bringen sollten, sich der oben beschriebenen Philosophie anzuschließen. Das Team, an dem ich arbeite, nimmt es von ganzem Herzen an. Infolgedessen ist die Quellcodeverwaltung ein reibungsloses Teammitglied, das uns hilft, unsere Arbeit zu erledigen.

Menschen, die diese Philosophie nicht akzeptieren, verursachen normalerweise zerbrochene Fenster und sind oft frustriert über die Quellcodeverwaltung. Sie sehen es bestenfalls als notwendiges Übel und im schlimmsten Fall als etwas, das sie vermeiden sollten. Dies führt zu seltenen Checkins, was bedeutet, dass Änderungssätze sehr groß und schwer zusammenzuführen sind, was die Frustration verstärkt, Checkins zu etwas macht, das noch mehr vermieden werden muss usw. Dies ist letztendlich eine Einstellungssache, nicht wirklich eine Prozesssache. Es ist leicht, mentale Barrieren dagegen zu errichten. Es ist leicht, Gründe zu finden, warum es nicht funktioniert, genauso wie es leicht ist, Gründe zu finden, warum man keine Diät macht, wenn man es nicht wirklich will. Aber wenn Menschen dies tun wollen und sich dazu verpflichten, ihre Gewohnheiten zu ändern, sind die Ergebnisse dramatisch. Es liegt an Ihnen, es effektiv zu verkaufen.

"Nie" ist selten ein gutes Wort für Richtlinien.

Ihr Kollege hat ein gutes Beispiel dafür, wann es angebracht sein könnte, auskommentierten Code einzuchecken: Wenn er unvollständig ist und die Anwendung möglicherweise beschädigt, wenn er eingecheckt wird, während er aktiv ist.

In einem gut verwalteten, änderungsgesteuerten System ist das Auskommentieren von totem Code größtenteils nicht erforderlich. Aber nicht jeder kommentierte Code ist "tot".

Auskommentierter Code sollte niemals eingecheckt werden, um den Verlauf aufrechtzuerhalten. Das ist der Punkt der Quellcodeverwaltung.

Hier wird viel über Ideale gesprochen. Vielleicht muss ich anders als alle anderen an mehreren Projekten mit mehreren Unterbrechungen arbeiten, wobei die "reale Welt" gelegentlich meinen Arbeitstag unterbrach.

In Wirklichkeit muss ich manchmal teilweise vollständigen Code einchecken. Es besteht entweder die Gefahr, dass der Code verloren geht oder dass unvollständiger Code eingecheckt wird. Ich kann es mir nicht immer leisten, eine noch so kleine Aufgabe zu "erledigen". Aber ich werde nicht meinen Laptop vom Netz trennen , ohne Check-in jedem Code.

Bei Bedarf werde ich einen eigenen Arbeitszweig erstellen, um teilweise Änderungen vorzunehmen.

Ein Fall, in dem ich auskommentierten Code weglasse:

// This approach doesn't work
// Blah, blah, blah

wenn das die offensichtliche Herangehensweise an das Problem ist, aber einen subtilen Fehler enthält. Sicher, das Repository würde es haben, aber das Repository würde in Zukunft niemanden warnen, diesen Weg nicht zu gehen.

Ich würde auf jeden Fall davon abraten, jemals auskommentierten Code einzuchecken. Ich würde es jedoch nicht absolut verbieten. Manchmal (wenn auch selten) ist es angebracht, auskommentierten Code in die Quellcodeverwaltung einzuchecken. "Mach das nie" zu sagen ist zu restriktiv.

Ich denke, wir sind uns alle in folgenden Punkten einig:

• Überprüfen Sie niemals toten Code in der Quellcodeverwaltung
• Überprüfen Sie niemals defekten (nicht funktionierenden) Code in der Quellcodeverwaltung, zumindest niemals in der Amtsleitung und nur sehr selten in einer privaten Zweigstelle, YMMV
• Wenn Sie zu Debugging-Zwecken vorübergehend etwas auskommentiert oder beschädigt haben, checken Sie den Code erst ein, wenn Sie den Code in seiner korrekten Form wiederhergestellt haben

Einige von ihnen sagen, dass es andere Kategorien gibt, wie vorübergehend entfernten Code oder eine inkrementelle, aber unvollständige Verbesserung, die eine kleine Menge auskommentiertem Code als Dokumentation für das, was als nächstes kommt, oder einen sehr kurzen (idealerweise 1 Zeile) Ausschnitt aus Kommentaren enthält out Code, der etwas zeigt, das niemals wieder hinzugefügt werden sollte. Auskommentierter Code sollte IMMER von einem Kommentar begleitet werden, der angibt, warum er auskommentiert (und nicht nur gelöscht) wird und die erwartete Lebensdauer des auskommentierten Codes angibt. Beispiel: "Der folgende Code schadet mehr als er nützt, ist also auskommentiert, muss jedoch vor Release XXX ersetzt werden."

Ein Kommentar wie der oben genannte ist angemessen, wenn Sie einen Hotfix bereitstellen, um die Blutung eines Kunden zu stoppen, und Sie nicht sofort die Möglichkeit haben, den endgültigen Fix zu finden. Nach der Übermittlung des Hotfixes erinnert der auskommentierte Code daran, dass noch etwas repariert werden muss.

Wann checke ich auskommentierten Code ein? Ein Beispiel ist, wenn ich versuchsweise etwas entferne, von dem ich glaube, dass es mit hoher Wahrscheinlichkeit in naher Zukunft in irgendeiner Form wieder hinzugefügt werden muss. Der auskommentierte Code soll direkt daran erinnern, dass dies unvollständig ist. Sicher, die alte Version befindet sich in der Quellcodeverwaltung und Sie können einfach einen FIXME- Kommentar als Flag verwenden, dass etwas mehr benötigt wird. Manchmal (wenn nicht oft) ist Code jedoch der bessere Kommentar.

Wenn ein Fehler durch Entfernen einer Codezeile (oder seltener zwei Codezeilen) behoben wird, kommentiere ich die Zeile manchmal nur mit einem Kommentar aus, um diesen Code aus einem bestimmten Grund nie wieder zu aktivieren. Diese Art von Kommentar ist klar, direkt und prägnant.

Rex M sagte: 1) Nur die vollständige Funktionalität einchecken, 2) [Wenn] die Aufgabe zu groß ist - teilen Sie sie in kleinere abschließbare Aufgaben auf.

Antwort: Ja, das ist das Ideal. Manchmal ist keine der beiden Optionen erreichbar, wenn Sie an Produktionscode arbeiten und ein sofortiges, kritisches Problem zu beheben haben. Manchmal müssen Sie zum Ausführen einer Aufgabe eine Weile eine Codeversion in das Feld einfügen. Dies gilt insbesondere für Änderungen am Datenerfassungscode, wenn Sie versuchen, die Hauptursache eines Problems zu finden.

Für die spezifische Instanz, nach der in der allgemeineren Frage gefragt wird ... solange der Entwickler auskommentierten Code in einer privaten Zweigstelle eincheckt, die niemand außer diesem Entwickler (und möglicherweise jemandem, mit dem der Entwickler zusammenarbeitet) sieht, es schadet wenig. Aber dieser Entwickler sollte (fast) niemals solchen Code in Trunk oder einen gleichwertigen Code liefern. Kofferraum sollte immer bauen und immer funktionieren. Es ist fast immer eine sehr schlechte Idee, unfertigen Code an Trunk zu liefern. Wenn Sie einen Entwickler unfertigen oder temporären Code in eine private Zweigstelle einchecken lassen, müssen Sie sich darauf verlassen, dass der Entwickler nicht vergisst, den Code zu bereinigen, bevor er in den Trunk geliefert wird.

Um als Antwort auf Kommentare zu anderen Antworten zu verdeutlichen, wenn Code auskommentiert und eingecheckt ist, gehe ich davon aus, dass der Code funktioniert, wenn unkommentiert mit der Zeitspanne abfällt, in der der Code auskommentiert wurde. Offensichtlich enthalten Refactoring-Tools nicht immer Kommentare in ihrem Refactoring. Fast immer, wenn ich auskommentierten Code in die Produktion einbaue, dient der Code als verfeinerter Kommentar, etwas Spezifischeres als Prosa, dass dort etwas getan werden muss. Es ist nicht etwas, das ein langes Leben haben sollte.

Wenn Sie in jeder Quelldatei auskommentierten Code finden, stimmt etwas nicht. Das Ausliefern von auskommentiertem Code in den Trunk aus irgendeinem Grund sollte ein seltenes Ereignis sein. Wenn dies häufig vorkommt, wird es unübersichtlich und verliert seinen Wert.

Ich denke nie ist eine zu starke Bedingung.

Ich neige dazu, Kommentare abzugeben, einzuchecken, Tests durchzuführen, nachzudenken und Kommentare nach der nächsten Veröffentlichung zu entfernen.

Im Allgemeinen ist das Einchecken von auskommentiertem Code falsch, da dies zu Verwirrung bei denjenigen führt, die nicht der ursprüngliche Autor sind und den Code lesen oder ändern müssen. In jedem Fall ist der ursprüngliche Autor nach Ablauf von 3 Monaten häufig verwirrt über den Code.

Ich unterstütze die Überzeugung, dass der Code dem Unternehmen oder Team gehört und dass es in Ihrer Verantwortung liegt, Ihren Kollegen die Arbeit zu erleichtern. Das Einchecken von auskommentiertem Code, ohne auch einen Kommentar darüber hinzuzufügen, warum er beibehalten wird, bedeutet, Folgendes zu sagen:

Es macht mir nichts aus, wenn Sie am Ende verwirrt sind, warum dieses Zeug hier ist. Meine Bedürfnisse sind wichtiger als Ihre, weshalb ich dies getan habe. Ich habe nicht das Bedürfnis, Ihnen oder sonst jemandem zu rechtfertigen, warum ich das getan habe.

Auskommentierter Code wird für mich normalerweise als Zeichen der Respektlosigkeit eines weniger nachdenklichen Mitarbeiters angesehen.

Ich stimme im Großen und Ganzen dem Grundsatz zu, dass auskommentierter Code nicht eingecheckt werden sollte. Das Versionsverwaltungssystem ist eine gemeinsam genutzte Ressource, und Ihr Kollege verwendet ihn bis zu einem gewissen Grad als seinen persönlichen Notizblock. Dies ist für die anderen Benutzer nicht sehr rücksichtsvoll, insbesondere wenn Sie die Idee des gemeinsamen Eigentums an der Codebasis abonnieren.

Der nächste Entwickler, der diesen auskommentierten Code sieht, hat keine Ahnung, dass er in Arbeit ist. Ist er frei, es zu ändern? Ist es toter Code? Er weiß es nicht.

Wenn sich die Änderung Ihres Kollegen nicht in einem Zustand befindet, in dem sie eingecheckt werden kann, muss er sie beenden und / oder lernen, kleinere, inkrementelle Änderungen vorzunehmen.

"Einchecken von Teiländerungen, die möglicherweise bereitgestellt werden oder nicht" - vermutlich bedeutet dies auch, dass sie getestet werden können oder nicht? Das ist ein rutschiger Hang zu einer sehr seiligen Codebasis.

Wenn Sie innerhalb der nächsten 3 Minuten eine kleine Funktion oder Fehlerbehebung wie JETZT hinzufügen müssen und eine Datei reparieren müssen, auf der Sie einen halb entwickelten Code haben, würde ich sagen, dass es in Ordnung ist, dass praktische Anforderungen über pragmatische Ideale auf dem Schlachtfeld herrschen.

Dies zeigt einen grundlegenden Unterschied zwischen zwei Denkrichtungen: Diejenigen, die nur Arbeitscode einchecken, mit dem sie zufrieden sind und der es wert ist, gespeichert zu werden, und diejenigen, die ihre Arbeit einchecken, damit die Revisionskontrolle dazu dient, sie gegen Datenverlust zu schützen.

Letzteres würde ich als "diejenigen bezeichnen, die ihr Revisionskontrollsystem gerne als Bandsicherung für arme Leute verwenden", aber das würde mir die Hand geben, in welchem ​​Lager ich mich befinde. :-)

Ich vermute, Sie gehören zum Lager des "guten Codes", und er gehört zum Lager des "Arbeitscodes".

[BEARBEITEN]

Aus den Kommentaren habe ich ja richtig geraten.

Wie gesagt, ich bin bei Ihnen, aber soweit ich das beurteilen kann, ist dies eine Minderheitsmeinung, sowohl hier zum Stackoverflow als auch dort, wo ich arbeite. Daher glaube ich nicht, dass Sie es wirklich in Ihren Entwicklungsstandards als einzige Möglichkeit zum Betrieb verankern können. Nicht, wenn Sie möchten, dass die Standards trotzdem eingehalten werden. Eine Sache, die ein guter Führer weiß, ist, niemals einen Befehl zu erteilen, von dem er weiß, dass er nicht befolgt wird.

Übrigens: Gut Editoren helfen dabei, alte Versionen . In Emacs habe ich beispielsweise alte Versionen und alte Versionen auf 10 gesetzt, wodurch die letzten 10 Speicherungen meiner Dateien beibehalten werden. Sie könnten dies als einen Weg betrachten, um Ihre Argumentation gegen die Menge der Revisionskontrolle als Backup zu unterstützen. Sie werden das Argument jedoch nie gewinnen.

Nach meiner Erfahrung sind Entwickler-Switches auskommentierter Code.

Manchmal werden parallel neue Back-Ends erstellt, wobei die aktivierenden Schalter in der Quellcodeverwaltung auskommentiert werden.

Einige bizarre Funktionen, die wir einmal auf einem blauen Mond benötigen, die aber kein Kunde jemals benötigen wird, werden häufig auf diese Weise implementiert. Diese Dinge bergen normalerweise ein hohes Risiko für die Umgehung der Sicherheit oder der Datenintegrität, sodass wir nicht möchten, dass sie außerhalb der Entwicklung aktiv sind. Die Anforderung eines Entwicklers, der den Code zuerst auskommentieren würde, scheint der einfachste Weg zu sein, ihn zu erhalten.

Ein weiterer Grund für den eingecheckten auskommentierten Code:

Sie ändern vorhandenen Code und haben einen subtilen Fehler gefunden, der leicht zu übersehen ist und möglicherweise auf den ersten Blick sogar richtig aussieht. Kommentieren Sie es aus, setzen Sie das Update an seine Stelle und fügen Sie Kommentare hinzu, was gerade passiert und warum es geändert wurde. Aktivieren Sie diese Option, damit sich Ihre Kommentare zum Fix im Repository befinden.

Vielleicht ist die eigentliche Frage hier, ob Entwickler unvollständigen Code einchecken dürfen?

Diese Praxis scheint Ihrem erklärten Ziel, eine kontinuierliche Integration zu implementieren, zu widersprechen.

Es hängt davon ab, ob. Wenn es zu Illustrationszwecken dort gelassen wird, vielleicht. Dies kann möglicherweise beim Refactoring hilfreich sein. Ansonsten und generell nein. Das Auskommentieren von unvollendetem Code ist sowohl fehleranfällig als auch zeitlich begrenzt. Besser, er zerlegt den Code in kleinere Teile und checkt sie ein, wenn sie funktionieren.

Meiner Ansicht nach: Wenn Entwickler an ihren eigenen Niederlassungen oder in ihrem eigenen Sandbox-Bereich arbeiten, sollten sie in der Lage sein, einzuchecken, was sie wollen. Wenn sie Code in einen gemeinsam genutzten Zweig (einen Feature-Zweig oder einen Team-Zweig oder natürlich MAIN / Trunk) einchecken, sollte der Code so makellos wie möglich sein (kein auskommentierter Code, keine FIXMEs mehr usw.).

Ich denke, "Nie" ist eine zu starke Regel. Ich würde dafür stimmen, einen persönlichen Spielraum zu lassen, ob Leute kommentierten Code in das Repository einchecken. Das ultimative Ziel sollte die Codiererproduktivität sein, nicht "ein makelloses Repository".

Um diese Nachlässigkeit auszugleichen, stellen Sie sicher, dass jeder weiß, dass auskommentierter Code ein Ablaufdatum hat. Jeder darf den kommentierten Code löschen, wenn er eine ganze Woche existiert und noch nie aktiv war. (Ersetzen Sie "eine Woche" durch das, was sich für Sie richtig anfühlt.) Auf diese Weise behalten Sie sich das Recht vor, Unordnung zu beseitigen, wenn Sie sie sehen, ohne den persönlichen Stil der Menschen zu direkt zu beeinträchtigen.

Ich stimme absolut zu, dass auskommentierter Code nicht in das Repository eingecheckt werden sollte, dafür ist die Quellcodeverwaltung gedacht.

Nach meiner Erfahrung ist ein Programmierer, der auskommentierten Code eincheckt, nicht sicher, was die richtige Lösung ist, und lässt die alternative Lösung glücklicher in der Quelle, in der Hoffnung, dass jemand anderes diese Entscheidung trifft.

Ich finde, dass es den Code kompliziert und das Lesen erschwert.

Ich habe kein Problem damit, halbfertigen Code einzuchecken (damit Sie den Vorteil der Quellcodeverwaltung erhalten), der vom Live-System nicht aufgerufen wird. Mein Problem besteht darin, Abschnitte mit kommentiertem Code ohne Erklärung zu finden. Das Dilemma bestand darin, dass der Code ausgeschlossen wurde.

Ich denke, das Einchecken von kommentiertem Code in ein Quellcode-Kontrollsystem sollte mit äußerster Vorsicht erfolgen, insbesondere wenn die zum Kommentieren des Codes verwendeten Sprach-Tags durch Blöcke geschrieben sind, dh:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Anstatt auf individueller Linienbasis wie:

// My commented code start here
// My commented code line 1
// My commented code line 2

(Du hast die Idee)

Der Grund, warum ich äußerst vorsichtig sein würde, ist, dass Sie je nach Technologie sehr vorsichtig mit dem von Ihnen verwendeten Diff / Merge-Tool sein sollten. Mit einem bestimmten Quellcodeverwaltungssystem und einer bestimmten Sprache kann das Diff / Merge-Tool leicht verwechselt werden. Das Standard-Diff / Merge von ClearCase ist beispielsweise für das Zusammenführen von XML-Dateien notorisch schlecht.

Wenn die Kommentarblockzeilen nicht ordnungsgemäß zusammengeführt werden, wird Ihr Code vorab im System aktiv, wenn dies nicht der Fall sein sollte. Wenn der Code unvollständig ist und den Build bricht, ist dies wahrscheinlich das am wenigsten Übel, da Sie ihn sofort erkennen werden.

Wenn der Code den Build besteht, wird er möglicherweise aktiv, wenn er nicht vorhanden sein sollte. Aus CM-Sicht kann dies ein Alptraumszenario sein. Die Qualitätssicherung testet im Allgemeinen, was vorhanden sein soll. Sie testet nicht auf Code, der nicht vorhanden sein soll, sodass Ihr Code möglicherweise in der Produktion landet, bevor Sie ihn kennen, und wenn erkannt wird, dass der Code vorhanden ist, wenn er vorhanden ist Sollte dies nicht der Fall sein, haben sich die Wartungskosten um ein Vielfaches vervielfacht (da der "Fehler" in der Produktion oder vom Kunden entdeckt wird, der schlechteste Ort oder die schlechteste Zeit aller Zeiten).

Die Idee, der Quellcodeverwaltungsgeschichte zu erlauben, die "alte Art" zu veranschaulichen, etwas zu tun, anstatt es zu kommentieren und das Kommentieren zusammen mit einer Erklärung einzuchecken, ist theoretisch eine gute Idee.

In der realen Welt betrachtet jedoch niemand den Verlauf der Quellcodeverwaltung für die Dateien, an denen er arbeitet, es sei denn, dies ist Teil eines offiziellen Überprüfungsprozesses (nur in regelmäßigen Abständen) oder wenn etwas nicht funktioniert, und der Entwickler kann nicht herausfinden warum.

Selbst dann passiert ein Rückblick auf mehr als 3 Versionen im Grunde nie.

Dies liegt zum Teil daran, dass Versionsverwaltungssysteme diese Art der gelegentlichen Überprüfung nicht einfach machen. Normalerweise müssen Sie eine alte Version auschecken oder sich von einer alten Version unterscheiden. Sie sehen nur zwei Versionen, und es gibt keine genaue Übersicht darüber, was sich geändert hat, sodass Sie auf einen Blick eine Vorstellung davon bekommen, was sich geändert hat.

Teilweise ist es die Kombination der menschlichen Natur und der Bedürfnisse des Teams. Wenn ich etwas reparieren muss und es in ein paar Stunden reparieren kann, werde ich wahrscheinlich keine Stunde damit verbringen, alte Versionen des Codes zu untersuchen, die seit einem Monat nicht mehr "live" waren (was jeder Entwickler überprüft bedeutet oft zurück viele Überarbeitungen), es sei denn, ich weiß zufällig, dass etwas drin ist (z. B. wenn ich mich an eine Diskussion über das Ändern von etwas erinnere, das mit dem zusammenhängt, was ich gerade mache).

Wenn der Code gelöscht und wieder eingecheckt wird, besteht er in jeder Hinsicht (mit Ausnahme des eingeschränkten Zwecks eines vollständigen Rollbacks) nicht mehr. Ja, es dient zu Sicherungszwecken, aber ohne eine Person in der Rolle des Codebibliothekars geht es verloren.

Mein Versionsverwaltungsbaum in meinem aktuellen Projekt ist ungefähr 10 Wochen alt, in einem Team von nur ungefähr 4 Ingenieuren, und es gibt ungefähr 200 festgeschriebene Änderungslisten. Ich weiß, dass mein Team beim Einchecken nicht so gute Arbeit leistet, wie es sollte, sobald etwas Festes und Bereites vorhanden ist. Das macht es ziemlich schwierig, sich darauf zu verlassen, den Codeverlauf für jeden Teil des Codes zu lesen, um jede wichtige Änderung zu erfassen.

Im Moment arbeite ich an einem Projekt im anfänglichen Entwicklungsmodus, der sich stark von einem Projekt im Wartungsmodus unterscheidet. Viele der gleichen Tools werden in beiden Umgebungen verwendet, aber die Anforderungen unterscheiden sich erheblich. Beispielsweise gibt es häufig eine Aufgabe, bei der zwei oder mehr Ingenieure eng zusammenarbeiten müssen, um etwas zu erstellen (z. B. einen Client und einen Server).

Wenn ich den Server schreibe, schreibe ich möglicherweise den Code für die Entwurfsschnittstelle, die der Client verwenden wird, und checke ihn vollständig funktionsunfähig ein, damit der Ingenieur, der den Client schreibt, aktualisieren kann. Dies liegt daran, dass wir die Richtlinie haben, die besagt, dass der einzige Weg, Code von einem Techniker an einen anderen zu senden, das Quellcodeverwaltungssystem ist.

Wenn die Aufgabe lange genug dauert, lohnt es sich, eine Zweigstelle zu erstellen, an der wir beide arbeiten können (obwohl dies gegen die Richtlinien in meiner Organisation verstößt - Ingenieure und einzelne Teamleiter verfügen nicht über die erforderlichen Berechtigungen der Versionsverwaltungsserver). Letztendlich ist es ein Kompromiss, weshalb wir versuchen, nicht zu viele "immer" oder "nie" Richtlinien einzuführen.

Ich würde wahrscheinlich auf eine solche Politik ohne kommentierten Code antworten, indem ich sage, dass sie ein bisschen naiv ist. Vielleicht gut gemeint, aber letztendlich unwahrscheinlich, dass es seinen Zweck erreicht.

Wenn Sie diesen Beitrag sehen, werden Sie den Code, den ich letzte Woche eingecheckt habe, noch einmal durchgehen und den auskommentierten Teil entfernen, der sowohl nie endgültig war (obwohl er funktioniert hat) als auch wahrscheinlich nie wieder gewünscht wird.

Ich denke, auskommentierter Code wird als "Verschwendung" angesehen.

Ich gehe davon aus, dass Sie in einer Teamumgebung arbeiten. Wenn Sie alleine arbeiten und Code mit einem 'todo' auskommentieren und darauf zurückkommen, ist das anders. In einer Teamumgebung können Sie jedoch davon ausgehen, dass der auskommentierte Code nach dem Einchecken erhalten bleibt und höchstwahrscheinlich mehr Schmerzen als Zufriedenheit verursacht.

Wenn Sie Peer-Code-Überprüfungen durchführen, wird Ihre Frage möglicherweise beantwortet. Wenn ein anderer Entwickler Ihren Code überprüft und sagt "Warum gibt es diesen auskommentierten Code, der versucht," bla "zu tun?", Hat Ihr Code die Codeüberprüfung nicht bestanden und Sie sollten ihn sowieso nicht einchecken.

Auskommentierter Code wirft nur Fragen bei anderen Entwicklern auf und verschwendet somit Zeit und Energie.

Sie müssen die Frage stellen " warum der Code auskommentiert ist. Einige Vorschläge:

Wenn Sie Code auskommentieren, weil Sie "nicht sicher sind, welche Geschäftsregeln gelten", haben Sie wahrscheinlich ein Problem mit "Scope Creep" - am besten verschmutzen Sie Ihre Codebasis nicht mit Anforderungen, die "schön wären, aber wir haben keine Zeit" zu implementieren "- halten Sie es sauber mit klarem Code und Tests rund um das, was tatsächlich da ist.

Wenn Sie Code auskommentieren, weil Sie "nicht sicher sind, ob dies der beste Weg ist", lassen Sie Ihren Code einer Peer-Review unterziehen! Die Zeiten ändern sich, Sie werden sich den Code ansehen, den Sie heute in 2 Jahren schreiben, und denken, dass er schrecklich ist! Aber Sie können nicht herumgehen und Dinge auskommentieren, von denen Sie wissen, dass sie besser gemacht werden können, aber Sie können gerade keinen Weg finden. Lassen Sie denjenigen, der die Codebasis langfristig verwaltet, entscheiden, ob es einen besseren Weg gibt - lassen Sie den Code einfach schreiben, testen und arbeiten und fahren Sie fort.

Wenn Sie Code auskommentieren, weil "etwas nicht funktioniert", dann FIX IT ! Ein häufiges Szenario sind "fehlerhafte Tests" oder "Aufgaben". . Wenn Sie diese haben, sparen Sie viel Zeit, indem Sie sie entweder reparieren oder einfach loswerden. Wenn sie für einen bestimmten Zeitraum "gebrochen" werden können, können sie höchstwahrscheinlich für immer gebrochen werden.

Alle diese potenziellen Szenarien (und diejenigen, die ich hier nicht erwähnt habe) sind Zeit- und Arbeitsverschwendung. Auskommentierter Code scheint ein kleines Problem zu sein, kann aber ein Indikator für ein größeres Problem in Ihrem Team sein.

Repositorys sind Sicherungskopien von Code. Wenn ich an Code arbeite, dieser aber noch nicht vollständig ist, können Sie ihn auskommentieren und am Ende des Tages einchecken. Auf diese Weise habe ich keine Arbeit verloren, wenn meine Festplatte über Nacht ausfällt. Ich kann den Code am Morgen auschecken, ihn auskommentieren und weitermachen.

Der einzige Grund, warum ich es auskommentieren würde, ist, dass ich den Build über Nacht nicht brechen möchte.

Es besteht eindeutig eine Spannung zwischen 1) frühem Einchecken und 2) ständigem Betrieb des Repositorys. Wenn Sie mehr als ein paar Entwickler haben, wird letzterer zunehmend Vorrang haben, da nicht ein Entwickler alle anderen für seinen persönlichen Workflow bescheißen kann. Das heißt , Sie sollten den Wert der ersten Richtlinie nicht unterschätzen. Entwickler verwenden alle Arten von mentalen Zaunpfosten, und individualisierte Workflows sind eine Möglichkeit, mit der großartige Entwickler diese zusätzlichen Xs herausdrücken können. Als Manager ist es Ihre Aufgabe, nicht zu versuchen, all diese Nuancen zu verstehen - an denen Sie scheitern werden, wenn Sie kein Genie sind und alle Ihre Entwickler Idioten sind -, sondern Ihren Entwicklern zu ermöglichen, durch ihre eigenen Entscheidungen das Beste zu sein, was sie können.

Sie erwähnen im Kommentar, dass Sie keine privaten Filialen verwenden. Meine Frage an Sie ist, warum nicht? Okay, ich weiß nichts über TFS, also gibt es vielleicht gute Gründe. Nachdem ich git ein Jahr lang benutzt habe, muss ich sagen, dass ein gutes DVCS diese Spannung völlig löst. Es gibt Fälle, in denen ich das Auskommentieren von Code als nützlich empfinde, wenn ich einen Ersatz baue, aber ich werde den Schlaf verlieren, wenn ich ihn anderen zufüge. In der Lage zu sein, lokal zu verzweigen, bedeutet, dass ich für meinen individuellen Prozess aussagekräftige Commits einhalten kann, ohne mich um nachgeschaltete Entwickler kümmern (oder sie sogar benachrichtigen) zu müssen.

Ich stimme nur dem Refrain zu. Entmutigen Sie dies um jeden Preis. Dies erschwert das Lesen des Codes und lässt die Leute sich fragen, was gut / schlecht an dem Code ist, der derzeit noch nicht einmal Teil der Anwendung ist. Sie können Änderungen immer finden, indem Sie Revisionen vergleichen. Wenn es eine größere Operation gab und der Code massenhaft auskommentiert wurde, hätte der Entwickler dies in den Revisionsnotizen zum Einchecken / Zusammenführen vermerken müssen.

unvollständiger / experimenteller Code sollte sich in einem Zweig befinden, der bis zur Fertigstellung entwickelt werden soll. Der Kopf / Rumpf sollte die Hauptlinie sein, die immer kompiliert wird und was Versand ist. Sobald der experimentelle Zweig abgeschlossen / akzeptiert ist, sollte er in den Kopf / die Hauptzeile eingefügt werden. Es gibt sogar einen IEEE-Standard (IEEE 1042), der dies beschreibt, wenn Sie Supportdokumentation benötigen.

Ich würde es vorziehen, wenn möglicherweise fehlerhafter, zugänglicher Code, der noch nicht verwendet wird, über denselben Code vollständig nicht verfügbar ist. Da jede Versionskontrollsoftware eine Art "Arbeitskopie" unabhängig vom Trunk zulässt, ist es wirklich eine viel bessere Idee, diese Funktionen stattdessen zu verwenden.

Neuer, nicht funktionierender Code ist im Trunk in Ordnung, da er neu ist. Es bricht wahrscheinlich nichts, was bereits funktioniert. Wenn der Arbeitscode beschädigt wird, sollte er nur in einen Zweig verschoben werden, damit andere Entwickler diesen Zweig (falls erforderlich) überprüfen und feststellen können, was fehlerhaft ist.

" Narbengewebe " nenne ich auskommentierten Code. In den Tagen vor der weit verbreiteten Verwendung von Versionskontrollsystemen ließen Code Monkeys auskommentierten Code in der Datei, falls sie die Funktionalität zurücksetzen mussten.

Das einzige Mal, dass es akzeptabel ist, "Narbengewebe" einzuchecken, ist

1. Wenn Sie eine private Niederlassung haben und
2. Sie haben keine Zeit, den Code fehlerfrei zu kompilieren und
3. Sie machen einen langen Urlaub und
4. Sie vertrauen Ihrem VCS nicht, beispielsweise wenn Sie Visual Source Safe OR verwenden .
   [BEARBEITEN]
5. Sie haben einen subtilen Fehler, der möglicherweise wieder eingeführt wird, wenn der falsche Code nicht als Erinnerung verwendet wird. (guter Punkt aus anderen Antworten).

Es gibt fast keine Entschuldigung für # 4, da es viele frei verfügbare und robuste VCS-Systeme gibt, wobei Git das beste Beispiel ist .

Andernfalls lassen Sie das VCS einfach Ihr Archiv- und Codeverteiler sein. Wenn ein anderer Entwickler Ihren Code anzeigen möchte, senden Sie ihm die Unterschiede per E-Mail und lassen Sie ihn die gewünschten Inhalte direkt anwenden. In jedem Fall ist es der Zusammenführung egal, warum oder wie die Codierung von zwei Dateien auseinander ging.

Da es sich um Code handelt, kann Narbengewebe sogar ablenkender sein als ein gut geschriebener Kommentar. Aufgrund seiner Natur als Code müssen Sie den Wartungsprogrammierer mentale CPU-Zyklen aufwenden, um herauszufinden, ob das Narbengewebe etwas mit seinen Änderungen zu tun hat. Es spielt keine Rolle, ob die Narbe eine Woche oder 10 Jahre alt ist. Das Belassen von Narbengewebe im Code belastet diejenigen, die die Code-Nachwörter entschlüsseln müssen.

[BEARBEITEN] Ich möchte hinzufügen, dass zwei wichtige Szenarien unterschieden werden müssen:

• private Entwicklung, entweder Codierung eines persönlichen Projekts oder Einchecken in eine private Niederlassung
• Wartungsentwicklung, bei der der eingecheckte Code in Produktion gehen soll.

Sag einfach "NEIN" zu Narbengewebe!

Ich weiß es nicht - ich kommentiere immer die ursprünglichen Zeilen aus, bevor ich Änderungen vornehme - es hilft mir, sie zurückzusetzen, wenn ich es mir anders überlege. Und ja, ich checke sie ein.

Ich entferne jedoch jeden alten kommentierten Code vom vorherigen Check-in.

Ich weiß, dass ich in den Diff-Protokollen nachsehen kann, was sich geändert hat, aber es ist ein Schmerz - es ist schön, die letzten Änderungen genau dort im Code zu sehen.

Ein guter Kompromiss besteht darin, ein kleines Tool zu schreiben, mit dem Ihre ausgecheckten / geänderten Dateien auf einem Netzwerksicherungslaufwerk gespeichert werden. Auf diese Weise können Sie nach Herzenslust Änderungen vornehmen und Ihre Arbeit sichern, müssen jedoch niemals experimentellen oder unvollendeten Code einchecken.

Ich denke, dass das Einchecken von auskommentiertem Code gültig sein sollte, nur weil die neue Änderung Tests bestanden hat, kann es hilfreicher sein, zu sehen, was vorher da war und ob die neue Änderung wirklich eine Verbesserung darstellt.

Wenn ich mehrere Versionen zurückgehen muss, um eine frühere Änderung zu sehen, die jetzt zu einem Leistungseinbruch führt, wäre das sehr ärgerlich.

Manchmal ist der auskommentierte Code eine gute Geschichte, aber geben Sie Daten an, wann der Code auskommentiert wurde. Später kann jemand, der in der Nähe arbeitet, den auskommentierten Code einfach löschen, da sich herausgestellt hat, dass er nicht benötigt wird.

Es wäre auch gut zu wissen, wer diesen Code auskommentiert hat, damit sie gefragt werden können, wenn eine Begründung erforderlich ist.

Ich bevorzuge es, neue Funktionen zu schreiben, sicherzustellen, dass die Komponententests bestanden werden, sie einzuchecken und dann anderen zu erlauben, sie zu verwenden und zu sehen, wie sie funktionieren.

Wenn der Entwickler hat einige Codes kommentiert, weil es noch nicht vollständig ist, dann ist die richtige „Quellcodeverwaltung“ Art und Weise damit umgeht für die Entwickler wäre es in einem separaten Zweig seiner eigenen zu halten, bis dieser Code ist bereit zu prüfen , im.

Mit einem DVCS (wie Git, Basar oder Quecksilber) ist dies kinderleicht, da keine Änderungen im zentralen Repository erforderlich sind. Andernfalls könnten Sie vielleicht darüber sprechen, Entwicklern ihre eigenen Zweige auf dem Server zu geben, wenn sie an bestimmten Funktionen arbeiten, die lange genug dauern (dh Tage).

Es ist nichts Falsches daran, auskommentierten Code in einigen Situationen einzuchecken. Es ist nur eine Situation, in der es möglicherweise eine bessere Möglichkeit gibt, dies zu tun, sodass der Entwickler Änderungen an seiner Quelle verfolgen kann , obwohl dies noch nicht geschehen ist im Haupt-Repository eingecheckt.

Es ist klar, dass der Entwickler, der auskommentierten Code eincheckt, in einem separaten Zweig arbeiten und Änderungen aus dem Trunk-Zweig nach Bedarf zusammenführen sollte.

Es ist Sache des VCS-Systems, den Entwickler bei diesem Workflow zu unterstützen (Git ist ein ausgezeichnetes VCS-System, das sehr gut damit funktioniert).