Das Formatieren von Code ist eine schlechte Sache, wenn Sie ein VCS verwenden?

Ich formatiere meinen Code fast immer vor dem Festschreiben, um sicherzustellen, dass er ordnungsgemäß ausgeführt wird. Die meisten meiner Mitarbeiter kümmern sich nicht wirklich darum und formatieren ihren Code nicht immer richtig (kleinere Dinge, die den Code nicht beeinflussen, aber die Lesbarkeit beeinträchtigen, wenn sie versuchen, ihn zu pflegen).

Ich habe kürzlich die VS-Elektrowerkzeuge mit der Option "Beim Speichern formatieren" installiert und eine Änderung an einer Datei vorgenommen, die zuvor nicht formatiert wurde. Der Entwicklungs-Vizepräsident kam gerade zu mir und tadelte mich wegen der Formatierung, da sich im Zusammenführungs-Tool herausstellte, dass fast die gesamte Datei geändert wurde, anstatt nur eine oder zwei Zeilen (er kann also nicht genau sehen, was ich leicht geändert habe), und Ich soll das Format beim Speichern in der Zukunft deaktivieren. Obwohl ich diese Bedenken verstehe, finde ich es manchmal schwierig, den nicht formatierten Code zu sortieren, und IMO sollte er sowieso immer richtig formatiert sein. Beachten Sie, dass ich nicht nur Dinge aus einer Laune heraus neu formatiere, sondern beim Schreiben von Code entweder das Elektrowerkzeug verwende oder den Tastaturbefehl drücke, um den Text so zu formatieren, dass er leichter zu lesen ist. In SVN wird dies als angezeigt eine Modifikation.

Also frage ich mich, ist das Formatieren des Codes immer eine schlechte Sache? Sind seine Bedenken zutreffender als sicherzustellen, dass der Code lesbar ist?

Zunächst muss Ihr Team eine Formatierungskonvention auswählen und diese einhalten. Sie müssen zu einer Einigung kommen und alle müssen sich daran halten, damit sich die Leute nicht streiten, wie die Dinge aussehen sollen. Dies sollte nicht nur etwas sein, das Sie alleine tun.

Wie für Ihre wirkliche Frage. Das Formatieren von Code ist keine schlechte Sache. Was schlecht ist, ist das Vornehmen größerer Formatierungsänderungen im selben Festschreiben wie Codeänderungen. Wenn sich Ihr Team darüber einig ist, wie die Dinge formatiert werden sollen, lassen Sie den Code einmal durchlaufen und formatieren Sie alles. Checken Sie das selbst ein. Die Festschreibungsmeldung macht deutlich, dass die Änderungen nur Leerzeichen sind und nicht funktionieren. Wenn Sie dann funktionale Änderungen vornehmen müssen, befinden sich diese in einem anderen Commit, damit sie klar erkennbar sind.

Nein, Formatierungscode ist sehr wichtig . Commits sollten jedoch in zwei Gruppen durchgeführt werden:

1. Kosmetische Änderungen - alles, was den Code lesbarer macht.
2. Die anderen Änderungen - alles andere, was den Code betrifft.

Verwenden Sie die Festschreibungsmeldung, um anzuzeigen, dass nur Kosmetika geändert wurden. Diese können bei der Suche nach umfangreicheren Änderungen leicht übersprungen werden.

Sie haben beide einen Punkt, aber Sie können beide bekommen, was Sie wollen. Formatieren Sie zuerst den Code und checken Sie nur diese Änderung ein. Nehmen Sie als Nächstes Ihre funktionalen Änderungen vor und überprüfen Sie dies als zweiten Schritt.

Ich bin auch ein Formatierer, also hier ein paar Tipps:

• Erforderlicher erster Schritt: Lassen Sie das Team einige grundlegende Formatierungsstandards vereinbaren, z. B. Tabulatoren oder Leerzeichen, geschweifte Positionen, Kommentarstile usw. Jetzt werden Ihre Formatierungsänderungen nicht mehr alle überraschen, und Sie werden nicht mehr schrittweise vorgehen auf alle Zehen.

• Bereinigen Sie die Formatierung nur um den Code, den Sie ändern. Wenn Sie nur an einer Funktion Änderungen vornehmen, bereinigen Sie diese Funktion. Zumindest im Laufe der Zeit werden Sie einen besser aussehenden Code haben.

• Führen Sie größere Überarbeitungen der Formatierung als separate Festschreibung durch, ohne dass sich der Code ändert. Sie sollten dies nur dann tun, wenn Sie den Code nach der Änderung seltener mit dem Code vor der Änderung vergleichen möchten, da der Vergleich mit einem solchen Diff ärgerlich sein kann. Normalerweise mache ich Bereinigungen als erstes, bevor ich mich mit diesem Code beschäftige.

• Holen Sie sich ein gutes Diff-Tool, mit dem Sie wichtige und unwichtige Änderungen sprachabhängig markieren können. Auch mein Lieblingsunterschied Beyond Compare kennzeichnet tatsächliche Codeänderungen in einer Farbe und Unterschiede zwischen Leerzeichen und Kommentaren in einer anderen.

für einen weiteren tipp editieren:

• Es variiert von Sprache zu Sprache, aber für die meisten wirklich kosmetischen Änderungen am Code sollten Sie kompilierte Binärdateien vor und nach einer größeren Bereinigung vergleichen können, um absolut sicherzugehen, dass Sie nichts falsch gemacht haben.

Sie sollten den Code anderer nicht neu formatieren und Änderungen vornehmen, es sei denn:

• Sie sind der Manager, der versucht, Team-Codierungsstandards festzulegen
• Ihr Manager hat Sie gebeten, den Code zu bereinigen, um die Team-Codierungsstandards einzuhalten
• Sie bereinigen den Code eines Entwicklers, der nicht mehr in Ihrem Team ist, um die Team-Codierungsstandards einzuhalten.

Sie werden in allen Fällen bemerken, dass ich mich auf Team-Codierungsstandards beziehe. Ich glaube fest an vernünftige, vereinbarte Kodierungsstandards für das Team. Wenn Sie sie haben, sollte der ursprüngliche Entwickler zurückgehen und seinen Code bereinigen, um die Teamstandards einzuhalten. Sie sollten dies nicht hinter ihrem Rücken tun. Wenn Sie keine Standards haben (und sollten), sollten Sie den Code eines anderen Teammitglieds nicht ändern, um sich an Ihre Philosophien zu halten, insbesondere nicht hinter deren Rücken. Denken Sie daran, dass Sie Teil eines Teams sind und dass Kodierungsstandards ebenso wichtig sind wie das Vertrauen und der Respekt zwischen den Teammitgliedern.