Hat Ihr Unternehmen einen Kodierungsstandard? [geschlossen]

Ich habe kürzlich gesehen, dass Microsoft ein Dokument mit Codierungsstandards ( All-In-One Code Framework Coding Standards ) veröffentlicht hat, und es hat mich zum Nachdenken gebracht ... Das Unternehmen, für das ich arbeite, hat überhaupt keine formalen Codierungsstandards. Es gibt nur wenige Entwickler und wir waren lange genug zusammen, um uns zu ähnlichen Stilen zu entwickeln, und es war nie ein Problem.

Verfügt das Unternehmen, für das Sie arbeiten, über dokumentierte Kodierungsstandards? Wenn nein, warum nicht? Macht es einen Unterschied, einen Standard zu haben? Lohnt es sich, einen Standard von Grund auf neu zu schreiben, oder sollten Sie einen anderen Standard als Ihren eigenen übernehmen (dh die Standards von Microsoft zu Ihren machen)?

Es ist wichtig, dass ein Team für jede Sprache einen einzigen Kodierungsstandard hat, um mehrere Probleme zu vermeiden:

• Ein Mangel an Standards kann Ihren Code unleserlich machen.
• Meinungsverschiedenheiten über Standards können zu Check-In-Konflikten zwischen Entwicklern führen.
• Es kann äußerst irritierend sein, unterschiedliche Standards in derselben Klasse zu sehen.

Ich bin ein großer Fan von dem, was Onkel Bob über Standards zu sagen hat :

1. Lassen Sie sie in den ersten paar Iterationen weiterentwickeln.
2. Lassen Sie sie teamspezifisch statt firmenspezifisch sein.
3. Schreiben Sie sie nicht auf, wenn Sie dies vermeiden können. Lassen Sie den Code vielmehr die Art und Weise sein, wie die Standards erfasst werden.
4. Legisliere kein gutes Design. (zB sag den Leuten nicht, dass sie goto nicht benutzen sollen)
5. Stellen Sie sicher, dass jeder weiß, dass es bei dem Standard um Kommunikation geht, und um nichts anderes.
6. Bringen Sie das Team nach den ersten Iterationen zusammen, um zu entscheiden.

Ich denke, es ist wichtig, einen Kodierungsstandard zu haben, auch wenn nur "Wir verwenden Einrückungen mit drei Leerzeichen und offene Klammern in der nächsten Zeile" steht. Ein paar Vorteile:

• Dies erleichtert das Lesen der gesamten Codebasis erheblich, da das Wechseln zwischen den Codierungsstilen zwischen Dateien ärgerlich ist.
• Dies erleichtert das Lesen einer einzelnen Datei, da jede Datei, die von zwei Entwicklern mit widersprüchlichen Stilen aktualisiert wird, letztendlich dazu neigt, diese Stile zu vermischen. Das Durchlesen einer Datei, in der Tabulatoren und Leerzeichen gemischt werden (und das spätere Bearbeiten), ist ärgerlich.
• Es macht es neuen Entwicklern leichter, einen guten Stil zu verwenden, wenn es einen expliziten und keinen impliziten Standard gibt.
• Konsistente Namenskonventionen erleichtern das Auffinden von Funktionen / Variablen erheblich. War es ArraySort oder array_Sort oder sortTheArray oder doSortArray oder ...?

In Bezug darauf, ob ein bestehender Standard übernommen werden soll, spielt es keine Rolle, dass es auf Konsistenz ankommt. Wenn Ihre Entwickler über ein Dutzend verschiedener Stile verfügen, können Sie auch einen vorhandenen, veröffentlichten auswählen. Wenn Sie sich alle zu einem ziemlich einheitlichen Stil entwickelt haben, schreiben Sie ihn einfach auf und verwenden Sie ihn.

Ich bin mit dem "wir sind ein X-Shop" nicht einverstanden, daher formatieren wir unseren Code in allen Sprachen auf die gleiche Weise.

Persönlich habe ich festgestellt, dass die meisten Sprachen unterschiedliche akzeptierte Stile haben.

Ich kann es wirklich nicht ertragen, wenn C-Programmierer Java-Code mit C-Formatierung schreiben. Es sieht nicht nur nicht wie Java aus, sondern täuscht sie auch vor, dass sie andere C-ähnliche Praktiken in Java anwenden können.

Ich denke, wenn Sie einen Standard haben, sollte es pro Sprache sein

Mein ehemaliger Arbeitgeber hat einen Kodierungsstandard. Ich überlege mir auch, eine für mich zu dokumentieren.

Oder, wie Sie vorschlagen, einen anständigen existierenden Standard zu finden und diesen zu modifizieren / zu übernehmen. Für ein Unternehmen würde ich mit Sicherheit vorschlagen, dass es sich mit vorhandenen Codierungsstandards befasst, diese jedoch für die eigenen Bedürfnisse erstellt / modifiziert. Es ist nicht unbedingt erforderlich, eine von Grund auf neu zu erstellen. Es sollte jedoch darauf geachtet werden, dass der Kodierungsstandard für die Art der Software, die das Unternehmen erstellt, sinnvoll ist.

Ja, ein Kodierungsstandard macht einen Unterschied, aber es ist keine Wunderwaffe. Code ist besser lesbar, da es nicht so viele unterschiedliche Stilkonflikte gibt und einige häufige Fehler / Fallstricke vermieden werden können. Sogar mit einem Standard werden Sie einige Variationen in den Codierungsstilen haben, aber diese Variabilität wird reduziert. Das Ziel ist nicht, jede Variation zu vermeiden oder sich auf jede mögliche Situation vorzubereiten. Ein zu komplizierter Kodierungsstandard kann schlimmer sein als gar keiner.

Leider nicht. So hat jeder seine eigene Art, Abstände, Einrückungen usw. zu verwenden, alles gemischt (auf diese Weise müssen wir nicht einmal die "Schuld" -Funktion verwenden, um zu wissen, wer der Autor einer Codezeile ist!)

Aber im schlimmsten Fall schreibt jemand Variablen- und Klassennamen auf Italienisch, jemand anderes auf Englisch ...

Ich passe meinen Stil immer an die Sprache, Bibliothek und das Framework an, die ich verwende, damit ein Quellcode einheitlich und klar aussieht.

Beachten Sie, dass dies ein Codierungsstandarddokument ist, das speziell für das All-In-One-Code-Framework gilt.

Ich habe in verschiedenen Unternehmen gearbeitet, von denen einige einen bestehenden Standard hatten und von denen einige (die meisten) ich bei der Entwicklung des Standards mitgewirkt habe. Wenn Sie eine .NET-basierte Entwicklung durchführen (und auch wenn dies nicht der Fall ist, gelten die meisten Regeln weiterhin), sollten Sie sich die Framework-Designrichtlinien ansehen . Während dies speziell für das Schreiben öffentlich zugänglicher APIs gilt, gelten die meisten Richtlinien für jeden Code gleichermaßen.

Das größte Anliegen bei Codestandards ist es, sie relativ einfach und unkompliziert zu halten. Sie möchten, dass Entwickler in der Lage sind, die vorgestellten Richtlinien zu verinnerlichen. Daher ist es sinnlos, ihnen ein Dokument mit mehr als 50 Seiten zu geben. Sie können dieses Dokument weiterhin erstellen, wenn Sie Hintergrundinformationen, Beispiele usw. bereitstellen möchten, aber Sie möchten auch eine Lösung, die sich auf eine Reihe von Aufzählungsrichtlinien beschränkt. Ihr Kodierungsstandard muss auch ein flexibles, lebendiges Dokument sein, das sich im Zuge des technologischen Wandels ändern muss.

Coding Standard-Diskussionen führen zu Folgendem:

• Ja, Sie brauchen sie. Konsistenz und sauberer Code sind ein Grundstein für eine gute Entwicklung.
• Was sie sind, spielt fast keine Rolle, solange alle den gleichen Standards folgen.
• Schreiben Sie nicht Ihre eigenen, Sie werden in eine endlose und schmerzhafte Diskussion geraten. Es gibt viele, die beliebt sind.
• Wenn Sie öffentliche Standards (wie die auf MSDN ) verwenden, erhalten Sie eine agnostische Drittpartei, mit der Sie nicht argumentieren können. Wenn Sie mit ihnen streiten möchten, lesen Sie Punkt 2.

Wenn Sie in Visual Studio in C # entwickeln, ist StyleCop ein Wundermittel . Wenn Sie auch ReSharper verwenden, ist das StyleCop for ReSharper- Plugin einfach fantastisch.

Wir sind ein Blub-Shop, daher verwenden wir die Blub-Programmierkonventionen.

Jetzt sind Paul Graham und seine Freunde viel schlauer als wir, aber wir Blub-Programmierer können uns alle gegenseitig lesen. Tatsächlich kann jeder Blub-Programmierer unseren Blub-Code lesen.

Tatsächlich kann jeder Blub-Programmierer aufgrund des Entwurfs von Blub jede einzelne Blub-Datei lesen und verstehen, da Blub kein Makrosystem hat.

Wenn wir in C oder C ++ programmieren (wir sind alle mehrsprachig, obwohl wir in Blub programmieren), verwenden wir meistens den Blub-Stil für neuen Code oder für Open Source-Inhalte, den Standard des Projekts, in dem wir arbeiten.

Sie benötigen einen Standard. Ich habe verschiedene Standards in verschiedenen Ecken einer Anwendung gesehen, die unterschiedliche Zuleitungen hatten, die alle "auf ihre Weise" ausführen wollten. Vielleicht wurde der Begriff "Standard" missverstanden. Sehr verrückt. Und die schlechtesten Standards werden von einer Person erzeugt. Egal wer diese Person ist, wenn nur eine Person den Standard entwickelt, ist es fast sicher, dass er schlecht ist.

Es kann Menschen helfen, es kann auch wirklich mit Werkzeugen helfen:

Wenn Sie in der Lage sein möchten, jede Art von automatischer Code-Formatierung zu verwenden, müssen Sie die Regeln, die verwendet werden sollen, wirklich standardisieren. Andernfalls werden Sie ständig eine Menge bedeutungsloser Formatierungsänderungen erhalten, die Ihre Diffs überfrachten.

Standard-Regelsätze für statische Analysewerkzeuge suchen möglicherweise nach einem bestimmten Benennungsstil, und es ist wahrscheinlich einfacher, sich daran zu halten, als eine Reihe neuer Regeln zu schreiben. (es sei denn, Sie schalten die Regel einfach ganz aus.)

Schließlich ist es gut, alles zu standardisieren, was mit jemandem außerhalb Ihres Teams besprochen werden muss. Das heißt, Sie möchten wahrscheinlich einen Standard-Copyright-Hinweis in Ihren Kopfzeilen, da Sie nicht jede neue Datei ausführen möchten, die Sie an der Rechtsabteilung Ihres Unternehmens vorbei schreiben, und Sie möchten auf jeden Fall die Namen aller öffentlichen APIs gleich beim ersten Mal richtig anzeigen