Wenn ich auf einen unkritischen Tippfehler im Code stoße (z. B. einen fehlerhaften Apostroph in einer Druckanweisung (Fehleranweisung)), lohnt es sich, diesen Fehler zu beheben, oder sollte er einfach in Ruhe gelassen werden?

Insbesondere bin ich neugierig darauf, das Aufsummieren des Commit-Protokolls gegen den Wert der Lösung dieser nicht kritischen Tippfehler abzuwägen. Ich neige dazu, sie aufzulösen. Bin ich pedantisch?

Ich persönlich bin der Meinung, dass die Verbesserung der Qualität die geringfügige Unannehmlichkeit eines zusätzlichen Eintrags im Festschreibungsprotokoll wert ist, selbst bei kleinen Verbesserungen. Schließlich zählen kleine Verbesserungen viel, wenn Sie den Effekt der zerbrochenen Fenster berücksichtigen .

Möglicherweise möchten Sie ein TRIVIAL:Tag voranstellen oder es als trivial markieren, wenn Ihr VCS dies unterstützt.

Sie sind nicht pedantisch, und es ist besser, sie einzeln zu lösen. Je atomarer eine Änderung ist, desto besser - Sie möchten nicht, dass ein abstürzender Bugfix mit 500 Kommentar- / Tippfehleränderungen verwechselt wird.

Im allgemeinen Fall: Ja

Es lohnt sich immer, die Wartbarkeit Ihrer Software zu erhöhen .

TU es einfach.

Wenn Sie gerade dabei sind, eine Veröffentlichung zu veröffentlichen ...

... und wenn Sie nicht der Teamleiter sind, wenden Sie sich an ihn .

Zum Inhalt des Commit-Logs ...

Ich stimme anderen zu, dass Sie zumindest etwas schreiben sollten, um es von "Feature" -bezogenen Commits zu unterscheiden, wenn es nur darum geht, einen isolierten Tippfehler zu beheben.

Es ist eine gängige Praxis, einige unendliche Aufgaben in Ihrem Issue-Tracker zu haben, um zeitlose und endlose Änderungen zu verfolgen. Zum Beispiel ist es nicht ungewöhnlich, eine Aufgabe zu haben für:

• große automatisierte harmlose Bereinigungen (Whitespaces Sweeps),
• Grammatik- und Tippfehlerjagd,
• Systemmodifikationen erstellen,
• usw...

Seien Sie nur vorsichtig, dass diese nicht als Wegwerf-Aufgaben-ID für irgendetwas verwendet werden, wenn die Leute faul werden, korrekt dokumentierte Tickets zu erstellen. Vor allem, wenn Sie Commits ablehnen, die nicht mit einer ID verknüpft sind (was gut ist, aber große Aufgaben wie diese für faule Entwickler noch attraktiver sind).

Tippfehler sollten als Commit hinzugefügt werden. Das Korrigieren von falsch geschriebenen Wörtern oder Grammatikfehlern verbessert die Lesbarkeit Ihres Codes.

Durch die Verwendung einer Festschreibungsmeldung wie "Fixed Typo" oder "Fixed Typo in file.c" können Sie diese Festschreibungen von anderen wichtigen Code-Festschreibungen unterscheiden.

Ja, das sollten Sie unbedingt tun, besonders zu Beginn eines Projekts.

Warum? Zwei Punkte:

1. Sie werden wahrscheinlich nicht wissen, ob ein Tippfehler "kritisch" ist oder nicht, bis es zu spät ist. Einige Fehlerbehebungen werden wahrscheinlich nicht behoben, weil jeder denkt, dass es keine große Sache sein wird. Bis es soweit ist.

2. Das frühzeitige und gezielte Beheben eines Tippfehlers ist viel einfacher als das Beheben, nachdem mehrere hundert Code- / Funktionszeilen damit ausgeführt wurden. Wiederum können temporäre Hacks überraschend schnell semipermanent werden. Aus diesem Grund muss ich mich mit Objekten befassen, die sowohl die Methoden "CollapseAll" als auch "ColapseAll" haben.

Bei Grammatikfehlern, die von einem Endbenutzer gesehen werden können, lohnt es sich auf jeden Fall, ein Commit durchzuführen, da es durchaus möglich ist, dass ein Benutzer oder eine Qualitätssicherung den Fehler meldet und nachverfolgt werden muss. Wenn es bereits behoben ist, kann es die Zeit verkürzen, die zur Behebung des Problems benötigt wird.

Wenn es sich jedoch um einen grammatikalischen Fehler in den Kommentaren zum Code handelt, würde ich nichts dagegen unternehmen, es sei denn, dies ist Teil der Änderungen am eigentlichen Code. In diesem Fall aktualisieren Sie die Dokumentation des Codes.

Wenn Sie befürchten, das Commit-Protokoll zu verfälschen, tun Sie etwas anderes. :-) Häufige Commits sind eine gute Sache! Ich beende die ganze Zeit Tippfehlerbehebungen. Holen Sie sie sich so schnell wie möglich in die Codebasis und beschleunigen Sie den Entwicklungszyklus!

Ich stimme ja. Checken Sie sie ein. Ich habe für eine Firma gearbeitet, die es hasste, Leute einzuchecken. Ich meine fast alles. Die Code-Überprüfungen waren umfangreich. Sie können sich den Zustand des Codes vorstellen. Eigentlich war der Code nicht schrecklich, aber er sickerte eher wie Melassesirup als wie Wein.

Ermöglicht Ihr Change Management-Prozess dies?

In meiner Umgebung muss jedes von mir getätigte Commit an eine Änderungsanforderung gebunden sein, die entweder von den Geschäftsbenutzern angefordert wurde, oder an eine obligatorische Änderung auf Systemebene, einschließlich der entsprechenden Endbenutzertestprozesse. Ein einfacher Tippfehler, wie Sie ihn beschreiben, würde wahrscheinlich nicht als einer dieser Fehler protokolliert werden (ich habe Tippfehler und grammatikalische Fehler in einer meiner Apps gefunden, die über 4 Jahre bestanden, ohne dass jemand etwas davon mitbekam) Ich würde es sehr schwer haben, mich selbst zu erklären.

Ich würde eine Änderung, wie Sie sie beschreiben (und tatsächlich eine haben - ein Methodenname ist falsch geschrieben und ich habe sie gerade entdeckt) für eine Zeit speichern, in der ich eine "echte" Änderung haben muss, die sein muss auch gemacht und "verschiedene Tippfehler behoben" ins Log geschrieben.

Verwenden Sie DVCS, um den Verlauf zu bearbeiten

Wenn Sie sich Sorgen über einen sauberen Festschreibungsverlauf machen, sollten Sie Ihre Hauptarbeit in Feature-Zweigen erledigen . Wenn Sie zufällig mit einem verteilten VCS arbeiten , können Sie Ihren Festschreibungsverlauf problemlos bearbeiten, bevor Sie ihn in den Hauptzweig verschieben. Wenn Sie auf SVN sind, probieren Sie Git aus - es kann bidirektional mit Subversion interagieren und Sie können den Verlauf auch bearbeiten, bevor Sie sich tatsächlich für Subversion verpflichten.

Behalte den gesunden Menschenverstand bei

Wenn Sie den Commit-Verlauf nicht bearbeiten möchten oder können, gibt es keinen funktionalen Grund, einen frühen oder atomaren Commit für einen geringfügigen Tippfehler durchzuführen, der die automatischen Tests oder das Kompilieren nicht beeinträchtigt . In diesen Fällen sollte es meiner Meinung nach wichtiger sein, den Commit-Verlauf sauber zu halten, als wirklich atomare Commits durchzuführen. Das Mischen von ein oder zwei Tippfehler-Korrekturen mit einer "regulären" Änderung schadet keinem potenziellen Überprüfungsprozess. Möglicherweise möchten Sie jedoch mehrere triviale Korrekturen zu einem Commit zusammenfassen, z. B. beim "Aufräumen" nach einer größeren Codierungssitzung.

Beachten Sie, dass Funktionsfehler in einem atomaren Commit nach wie vor so schnell wie möglich festgeschrieben werden sollten.

Der allgemeine Ton der Antworten hier scheint darauf hinzudeuten, dass es sich auch bei geringfügigen Tippfehlern um eine Strategie handelt, die "alles schnell festlegt". Ich bin eher anderer Meinung und begrüße Diskussionen.