it-swarm.com.de

Wäre es eine schlechte Idee, regelmäßig Code-Formatierer in einem Repository auszuführen?

Ich denke darüber nach, einen Cron-Job zu erstellen, der Code auscheckt, Code-Formatierer darauf ausführt und die Änderungen festschreibt und zurückschiebt, wenn sich etwas ändert.

Die meisten Projekte, die Autoformater verwenden, setzen sie in einen Git-Hook ein, aber wenn sie alle paar Stunden automatisch ausgeführt werden, entfällt für jeden Entwickler die Last, den Git-Hook zu installieren.

Ich würde immer noch jeden ermutigen, sauberen, gut formatierten Code zu schreiben, und vielleicht kann das System Entwickler automatisch pingen, wenn der von ihnen geschriebene Code neu formatiert wird, damit sie wissen, was in Zukunft zu tun ist.

68
bigblind

Klingt nett, aber Ich würde es vorziehen, wenn Leute für das Begehen von Codeänderungen verantwortlich sind, nicht Bots.

Außerdem möchten Sie unbedingt sicherstellen, dass diese Änderungen nichts beschädigen. Zum Beispiel haben wir eine Regel, die Eigenschaften und Methoden alphabetisch sortiert. Dies kann sich auf die Funktionalität auswirken, z. B. mit der Reihenfolge der Daten und Methoden in WSDL-Dateien von WCF-Verträgen.

129
Marcel

Ich würde stattdessen versuchen, es jedem im Team wirklich einfach zu machen, die automatische Code-Formatierung gemäß dem Standard Ihres Teams direkt in Ihrem Editor oder Ihrer IDE auf die aktuelle Quellcodedatei (oder ausgewählte Teile davon) anzuwenden ). Auf diese Weise haben Ihre Teammitglieder mehr Kontrolle darüber, wie und wann die Formatierung erfolgt. Lassen Sie sie den Code überprüfen, bevor er in der endgültigen Form festgeschrieben wird, und testen Sie ihn nach der Formatierung, nicht vorher .

Wenn alle oder die meisten Ihrer Teammitglieder denselben Editor verwenden, sollte dies nicht zu schwierig sein. Wenn jeder einen anderen verwendet, ist Ihr Ansatz möglicherweise die zweitbeste Lösung, sofern das Team dies unterstützt. Ich empfehle jedoch, zusätzliche Sicherheitsmaßnahmen zu installieren, z. B. nächtliche Builds und automatisierte Tests, die ausgeführt werden nach jede automatische Codeänderung.

73
Doc Brown

Es ist eine schlechte Idee, nicht nur, weil sie die Leute davon abhält, anständigen Code zu schreiben, sondern auch, weil die Neuformatierung als Codeänderungen in Ihrem VCS angezeigt wird (Sie verwenden hoffentlich eine), wodurch der historische Ablauf der Codeentwicklung maskiert wird. Schlimmer noch, jede Code-Formatierungsaktion (in der Tat jede Änderung des Codes überhaupt) hat die Möglichkeit, Fehler einzuführen, egal ob manuell oder automatisiert. So kann Ihr Formatierer jetzt Fehler in Ihren Code einfügen, die erst möglicherweise Monate später Codeüberprüfungen, Komponententests, Integrationstests usw. durchlaufen.

37
jwenting

Ich würde eher glauben, dass es eine gute Idee ist (Code-Formatierer automatisch auszuführen), aber das ist nur meine Meinung.

Ich werde sie nicht regelmäßig ausführen, aber wenn möglich, bevor die Versionskontrolle festgeschrieben wird.

Mit git wäre ein Pre-Commit-Hook nützlich. In vielen C- oder C++ - Projekten, die mit Makefile erstellt wurden, füge ich ein indent -Ziel hinzu (auf dem geeignete Code-Formatierer wie indent oder ausgeführt werden astyle ) und erwarten, dass Mitwirkende make indent regelmäßig. Übrigens können Sie sogar einige make Regeln hinzufügen, um sicherzustellen, dass die Git-Hooks installiert wurden (oder um sie zu installieren).

Aber wirklich, es ist eher ein soziales Problem als ein technisches eins. Sie möchten, dass Ihr Team sauberen und gut formatierten Code festlegt, und das ist eine soziale Regel Ihres Projekts. (Es gibt nicht immer eine technische Antwort auf jedes soziale Problem).

Die Versionskontrolle ist meistens ein Werkzeug, um die Kommunikation zwischen menschlichen Entwicklern zu unterstützen (einschließlich Ihres eigenen Selbst in einigen Monaten). Ihre Software benötigt keine VC oder Formatierung), Ihr Team jedoch.

Übrigens haben verschiedene Communitys und verschiedene Programmiersprachen unterschiedliche Ansichten zur Code-Formatierung. Zum Beispiel hat Go nur einen Code-Formatierungsstil, aber C oder C++ haben viele davon.

28

Ich denke es ist eine schlechte Idee. Viele der Antworten betrafen bereits, dass es die Geschichte verschmutzt, indem es schwierig macht, festzustellen, wer tatsächlich eine Zeile hinzugefügt hat, und dass es die Leute dazu ermutigt, einfach irgendetwas zu begehen und der Format-Bot wird damit umgehen.

Ein besserer Ansatz wäre, eine Formatprüfung in Ihr Build-Tool zu integrieren. (In Java gibt es Checkstyle ) Erlauben Sie dann nur Personen, ihre Zweige mit dem Hauptzweig zusammenzuführen, wenn der Build erfolgreich ist (einschließlich der Formatierung).

Wenn Sie zulassen, dass Benutzer direkt in den Hauptzweig einbinden (wie zum Beispiel in Subversion), müssen Sie dennoch sicherstellen, dass jeder die Disziplin hat, nur formatierten Code festzuschreiben (oder dass der Server die Festschreibungen erst akzeptiert, nachdem einige Überprüfungen ausgeführt wurden ).

17
Captain Man

Im Allgemeinen halte ich es für eine schlechte Idee. Im Prinzip ist es eine gültige Idee, aber es kann in der Realität problematisch sein. Es ist eine echte Möglichkeit, dass der Code-Formatierer Ihren Code bricht, und es dauert nur einen Formatierungslauf, bis Ihre Entwickler mit (wahrscheinlich gerechtfertigter) Feindseligkeit reagieren (z. B. "Ihr mieser Code-Formatierer hat den Build gebrochen, schalten Sie ihn aus - jetzt! ").

Ähnlich wie bei der Empfehlung von @ BasileStarynkevitch verwenden wir git-serverseitige Post-Receive-Hooks, um "Beratungs-E-Mails" zum Codestil zu senden.

Wenn ich ein Commit pushe, das Stilverletzungen enthält, sendet mir der Git Origin-Server eine E-Mail, die mich darüber informiert, dass ich gegen die Stilrichtlinien verstoßen habe, und empfiehlt, dass ich meinen Code korrigiere. Dies wird jedoch nicht erzwungen, da es möglicherweise triftige Gründe gibt, den Hausstil zu brechen (z. B. lange Zeichenfolgen, die die Zeilenlängenbeschränkung überschreiten).

Wenn es sich um ein systembedingtes Problem handelt, das die Codebasis beschädigt, ist es möglicherweise an der Zeit, Probleme mit dem Codestil in Codeüberprüfungen anzusprechen. Ein schlechter Codestil kann Fehler maskieren und das Lesen des Codes erschweren, sodass es sich möglicherweise um ein gültiges Problem bei der Codeüberprüfung handelt.

Um den Aspekt "soziales Problem" zu ergänzen, kann es sich lohnen, Menschen zu ermutigen, kosmetische und stilistische Mängel zu beheben, sobald sie sie finden. Wir haben eine Standard-Commit-Nachricht "Cosmetic". Für Code-Style-Fixes, von denen andere Entwickler wissen, dass sie keine wichtigen Änderungen enthalten.

Wie @DocBrown sagt, besteht eine weitere Option darin, den Codestil in Ihrer IDE zu erzwingen. Wir verwenden CodeMaid mit Visual Studio, um viele häufige Stilfehler zu korrigieren. Es wird beim Speichern der Codedateien ausgeführt, was bedeutet, dass Code im schlechten Stil niemals in das Repo gelangen sollte ... theoretisch :-).

16
Karl Nicoll

Ja, ich denke es ist eine schlechte Idee. Versteh mich nicht falsch, der Grund dafür klingt großartig, aber das Ergebnis könnte immer noch schrecklich sein.

Beim Ziehen eines verfolgten Zweigs treten Zusammenführungskonflikte auf. Zumindest befürchte ich, dass dies der Fall ist. Ich könnte mich jedoch irren.

Ich möchte es jetzt nicht bei der Arbeit testen, aber Sie sollten es selbst ausprobieren.

Tatsächlich können Sie sich einfach ein aktuelles Commit ansehen. Erstellen Sie einen neuen Zweig, legen Sie etwas Kleines fest, pflücken Sie eine Kirsche oder verschmelzen Sie ohne automatisches Festschreiben.

Führen Sie dann Ihr Skript aus, ziehen Sie es und wenn Ihr Ergebnis ein schreckliches Zusammenführungsproblem ist, sollten Sie dies bei Tageslicht definitiv nicht tun.

Stattdessen könnten Sie es möglicherweise in einen nächtlichen oder einen wöchentlichen Build umwandeln.

Aber auch eine Nacht könnte eine schlechte Idee sein.

Sie können es entweder wöchentlich ausführen, wenn Sie sicher sind, dass keine Zusammenführungskonflikte auftreten, da alles am Montag beendet ist.

Andernfalls führen Sie es in der Ferienzeit 1-2 Mal im Jahr aus, wenn keine Zusammenführungskonflikte auftreten.

Die Lösung hängt jedoch möglicherweise von Ihrer Priorität für den Codestil ab.

Ich denke, dass es besser wäre, ein Setup-Skript zu erstellen, das automatisch das Git-Repository erstellt und die Hooks für das Projekt festlegt.

Oder Sie können das Hook-Setup-Skript in einen Ordner für Ihre Entwickler in das Projekt aufnehmen und es einfach in Git selbst einchecken.

10

Was ich nicht erwähnt habe, ist die Tatsache, dass es manchmal legitime Gründe gibt, etwas nicht nach einer Reihe von Regeln zu formatieren. Manchmal wird die Klarheit des Codes verbessert, indem gegen eine bestimmte Richtlinie verstoßen wird, die in 99% der Fälle sinnvoll ist. Menschen müssen diesen Anruf tätigen. In diesen Fällen würde die automatische Code-Formatierung die Lesbarkeit beeinträchtigen.

7
Andy Lester

Es ist eine schreckliche Idee.

Wenn einer meiner Entwicklerkollegen unentgeltlich Änderungen an den Quelldateien vornehmen würde, würde er keine Codeüberprüfung bestehen. Es macht nur das Leben für alle schwerer. Ändern Sie den Code, der geändert werden muss, sonst nichts. Sinnlose Änderungen führen zu Zusammenführungskonflikten, die zu Fehlern führen können, und führen nur zu sinnloser Arbeit.

Wenn Sie dies regelmäßig tun möchten, ist das einfach schrecklich.

Und dann stellt sich die Frage, welche Art von Änderungen der Code-Formatierer vornimmt. Ich verwende die automatische Formatierung in meinem Editor, sie funktioniert recht gut und ich kann Dinge verbessern, wenn die automatische Formatierung nicht perfekt ist. Wenn Sie einen Code-Formatierer verwenden, der darüber hinausgeht, werden Sie den Code nicht verbessern, sondern verschlimmern.

Und dann ist da noch das soziale Problem. Es gibt Leute, die jeden zwingen wollen, ihren Codestil zu verwenden, und es gibt flexiblere Leute. So etwas würde wahrscheinlich der Entwickler vom Typ "Grammer-Nazi" (Rechtschreibung absichtlich) vorschlagen, der seinen Stil allen anderen aufzwingen möchte. Erwarten Sie eine Gegenreaktion und erwarten Sie, dass die flexiblen, normalerweise lockeren Entwickler ihren Fuß nach unten setzen.

7
gnasher729

Sie erwähnen das von Ihnen verwendete VCS nicht, aber abhängig davon besteht eine andere Option darin, einen serverseitigen Hook zu haben. Ein VCS wie git unterstützt das. Sie können einen Server-Hook installieren, der den Formatierer für die zu pushende Version ausführt und dann die formatierte Datei mit der Version vergleicht, die übertragen wird. Wenn sie sich unterscheiden, hat der Entwickler nicht die richtige Formatierung verwendet und der Server konnte den Push ablehnen. Dies würde Ihre Entwickler dazu zwingen, nur Code mit der gewünschten Formatierung zu pushen, was sie dazu ermutigt, von Anfang an sauberen Code zu schreiben. Dies würde die Entwickler dafür verantwortlich machen, den korrekt formatierten Code getestet zu haben, und Ihre Entwickler von der manuellen Installation einer clientseitigen Seite entlasten Haken.

4
sigy

Es ist ein Kompromiss zwischen einem saubereren Codeformat und einer genaueren und leichter verständlichen Git-Geschichte. Hängt von der Art Ihres Projekts ab und davon, wie oft Sie in die Git-Geschichte eintauchen oder beschuldigen, zu verstehen, was los ist. Wenn Sie an etwas Neuem arbeiten und keine Abwärtskompatibilität gewährleisten müssen, spielt der Verlauf normalerweise keine so wichtige Rolle.

1
Max Yankov

Diese Idee ähnelt einigen anderen Antworten, aber ich kann meine Vorschläge nicht kommentieren.

Eine Möglichkeit besteht darin, einen Alias ​​(oder Hook oder was auch immer) für die Festschreibungsfunktion festzulegen, der den Codeformatierer für den festzuschreibenden Code ausführt, bevor er festgeschrieben wird.

Es könnte 2 (oder mehr) Ergebnisse haben:

1) Zeigen Sie dem Benutzer die vorgeschlagenen Änderungen und bitten Sie ihn um seine Zustimmung, um die Änderungen zu übernehmen und festzuschreiben.

2) Ignorieren Sie die vorgeschlagenen Änderungen und übernehmen Sie den ursprünglichen Code.

Sie können diesen Optionen auch mehr Flexibilität hinzufügen, z. B. die Möglichkeit, die in Option 1 vorgeschlagenen Änderungen zu bearbeiten. Eine andere Idee (je nachdem, wie stark Sie diese Codierungsstandards verschieben möchten) besteht darin, dass das System Ihnen wann einen Bericht sendet Option 2 ist ausgewählt.

Dies kann eine gute Balance zwischen der automatischen Überprüfung des gesamten Codes wie gewünscht sein und den Entwicklern dennoch Flexibilität bieten, um ihren Anforderungen gerecht zu werden. Es ermöglicht auch die Option, Code mit Formatierungsunterschieden, wie in anderen Antworten erwähnt, nicht automatisch abzulehnen. Mit dem 'Ich habe automatische Formatierungskorrekturen überprüft und genehmigt; Mit der Option "Commit" bleibt die persönliche Verantwortung für die Arbeit jedes Entwicklers erhalten und es wird kein Problem mit VCS verursacht.

1
MadisonCooper

Ich werde es nicht im Repository tun, aber ich werde es beim Speichern tun, wenn das Tool es unterstützt. Eclipse ist eine und zusätzlich würde ich die Codebereinigung einschließlich Sortieren durchführen.

Der schöne Teil ist, dass es Teil des Projekts ist, so dass jeder Entwickler es für sein Projekt bekommt.

Als zusätzlichen Bonus würden Zusammenführungen erheblich vereinfacht, da die Dinge nicht herumspringen werden.

Codeüberprüfungen verhindern fehlerhafte.

Ein anderer Ort, an dem ich es tun würde, ist, es Teil des Builds zu haben. In meinem Fall habe ich es so, dass Maven Builds das XML neu formatieren und POM-Dateien bereinigen und den Code neu formatieren.

Auf diese Weise wird alles, was Entwickler für Push bereit sind, für ihre Pull-Anfrage bereinigt.

0