Erzwingen eines Codierungsstils

Question

Vor Jahren, als ich ein kleines Entwicklungsprojekt startete, haben sich die anderen Entwickler und ich hingesetzt und uns auf eine Kompromißklammer und einen Eindruckstil geeinigt. Es war niemandes Liebling, aber es war etwas, das niemand wirklich hasste. Ich habe eine .indentrc-Konfigurationsdatei für diesen Stil geschrieben und hatte einen Eincheck-Trigger, der beim Einchecken eine Einrückung für jede Datei ausführen würde. Das machte es so, dass es egal war, in welchen Stil du deinen Code geschrieben hast. es würde der Gruppenstandard werden, bevor irgendjemand anderes es gesehen hat. Dies hatte den Vorteil der Konsistenz. Aber ich habe noch nie zuvor jemanden gesehen, der es so oder so gemacht hat.

Also was sagen Sie den Rest von Ihnen? Tolle Idee oder Gräuel?

Answer 1

Eine neutrale Codierung ist definitiv eine gute Idee. Es kann aber durchaus sinnvoll sein, den Codierungsstil nur beim Einchecken der Quelle zu erzwingen (siehe auch Bill's und Elie' s Antworten unten).

Mit dem Check-in-Haken:

Pro: Ermöglicht Programmierer jedoch zu schreiben sie wollen, so dass sie nicht über den Standard denken oder wie sie Code schreiben, ändern. Dies minimiert den Widerstand gegen die Richtlinie und beeinträchtigt nicht ihre Produktivität beim Schreiben von Code.

Con: Ihre Programmierer haben vielleicht nur eine vorübergehende Vertrautheit mit dem neutralen Stil, so dass Sie nicht den vollen Nutzen von allen nutzen, die den "gleichen" Stil verwenden. Wenn Ihre Programmierer jemals in einer Paarprogrammierung zusammenarbeiten müssen, werden sie immer noch dem Programmierstil des anderen auf dem Bildschirm unterworfen sein, der sich von ihrem eigenen Stil oder dem neutralen Stil unterscheidet.

Einen Schritt weiter gehen, den neutralen Stil während der Entwicklung mit:

Pro. Geläufigkeit legt im neutralen Stil, jeder kann immer allen anderen Code lesen, bevor und nachdem sie eingecheckt hat

Con: Sie werden auf diese Weise mehr Widerstand von Ihren Entwicklern erfahren. Abhängig von deiner Kultur könnte es mehr Probleme geben, als es wert ist.

Answer 2

Das klingt nach einer guten Idee. Solange der Stil, mit dem Sie enden, nicht etwas völlig Seltsames ist, ist dies ein guter Weg, um sicherzustellen, dass Ihre Entwickler den Stil verwenden. Und es hat den zusätzlichen Vorteil, dass sie nicht auf diese Weise codieren müssen - es wird für sie neu formatiert, wenn sie ihre Änderungen einchecken. Es wäre schön, ein Tool wie dieses zur Verfügung zu haben, das Sie in Ihren CVS (Gattungsbegriff) stecken können.

Answer 3

Ich würde eine gute Idee sagen. Ich würde es noch einen Schritt weiter bringen und alle dazu bringen, die Konfigurationsdatei in ihrer IDE zu verwenden, so dass sie standardmäßig im vereinbarten Stil schreiben. Wenn sie sich im neutralen Stil den Code aller anderen ansehen müssen, können sie sich auch daran gewöhnen. Selbst der eigene Code sollte nach einem Check-in-Check-Out-Zyklus neutral sein. Warum also neuen Code in seinem eigenen persönlichen Stil entwickeln?

Answer 4

Wenn Sie es auf die Durchsetzung von Stil auf Klammern und Einrückung beschränkt, dann denke ich, es ist eine gute Idee. Wenn Sie jedoch versuchen würden, jeden einzelnen Formatierungsstandard zu erzwingen, wäre das wahrscheinlich nicht der Fall. Meiner Meinung nach gibt es Zeiten, in denen es Sinn macht, den Standard zu brechen. Zum Beispiel, ziehe ich

int x = y * z; 

zu

int x = y*z; 

weil es einfacher zu lesen. Allerdings habe ich es vorziehen, in beträchtlichem Ausmaß

int a = b*c + d*e; 

zu

int a = b * c + d * e; 

weil der Abstand die Reihenfolge der Operationen darstellt.

So klingt Ihre Politik der Durchsetzung von Einrückung und geschweiften Klammern wirklich gut. Aber wenn jemand jemals versuchte, andere Abstandsregeln blind zu erzwingen, glaube ich nicht, dass es gut funktionieren würde.

Answer 5

Wir verwenden TFS mit einer Eincheck-Richtlinie, die eine Reihe von Stylecop-Regeln ausführt. Wenn Ihr Code nicht besteht, können Sie ihn nicht einchecken. Funktioniert wirklich sehr gut. Abgesehen von einem konsistenten Stil und einer guten Kommentierung scheint es auch die allgemeine Qualität des Codes erhöht zu haben - vielleicht weil der Entwickler gezwungen ist zu beschreiben, welche Methode, Ereignis, etc. er vor dem Check mehr über den Code denken muss in.

Nur eine MS-Lösung, aber lohnt sich, wenn es Ihnen zur Verfügung steht.

Answer 6

Das größte Problem bei der Verwendung von automatischen Codeformatierern ist, wenn der Codeformatierer nicht jedes Szenario verarbeiten kann.

Zum Beispiel, wenn Sie viel SQL in Ihrem Code haben, formatieren Sie wahrscheinlich das SQL automatisch. Aber wenn Ihr SQL länger als eine Zeile ist (wie lang ist eine Zeile überhaupt?), Dann müssen Sie formatieren. Bisher habe ich noch keinen guten Formatierer gesehen, als dass ich richtig damit umgehen kann.

Beispiel:

String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = 'N'"; 

vs

String sql = 
    "SELECT * " + 
    "FROM USERS " + 
    "WHERE ID = ? " + 
    " AND NAME = ? " + 
    " AND IS_DELETED = 'N'"; 

Das zweite Format ist besser lesbar, wenn Sie wirklich lange Fragen haben. Die meisten Formatierer würden das in eine lange Zeile bis zur Zeilenlänge de-formatieren.

Allerdings, wenn alles, was Sie tun, dreht

if(x=1) print("blah"); else print("eep!"); 

in

if (x = 1) { 
    print("blah"); 
} else { 
    print("eep!"); 
} 

dann die Forma in Ordnung ist. Wir machen etwas ähnliches bei der Arbeit; Es wird nicht vom CVS-Tool, sondern von der IDE durchgesetzt. Funktioniert einigermaßen gut.

Answer 7

Ich glaube, dass Sie sich jetzt für Ihre Entwicklungsumgebung entschieden haben. Wenn Sie Eclipse verwenden, können Sie die Aktion zum Speichern der Formatquelle im Java-Editor aktivieren, der bei jedem Speichern neu formatiert wird. Der Hauptvorteil davon ist, dass die Quellchancen in Ihrem Quell-Repository zum Zeitpunkt ihrer Erstellung markiert sind und nicht, wenn die Quelle später neu formatiert wurde.

Machen Sie es zu einem automatischen Schritt. Sie werden es später zu schätzen wissen.

Answer 8

Es gibt ein Projekt namens EditorConfig kann das Problem etwas lösen. Derzeit löst es jedoch nur Einzugsprobleme.

EditorConfig enthält Plugins für many different editors und einen Dateiformatstandard. Wenn Sie im Stammverzeichnis Ihres Projekts eine .editorconfig Datei erstellen und das entsprechende Plugin installieren, formatiert der Editor Ihren Code bei der Eingabe.

Dies ist ein allgemeiner Weg (im Gegensatz zu indentrc, nicht beschränkt auf C/C++), aber Sie können immer noch einen Blick auf diese Lösung werfen.