Warum schlägt Onkel Bob vor, Codierungsstandards nicht aufzuschreiben, wenn Sie dies vermeiden können?

Während ich diese Frage las , zitierte die am häufigsten gewählte Antwort Onkel Bob zu Codierungsstandards , aber dieser Tipp verwirrte mich:

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.

Dies wirbelte in meinem Gehirn herum, aber ich fand keinen Platz zum Verweilen. Wenn eine neue Person dem Team beitritt oder sich die Kodierungsstandards ändern, kann es dann zu Informationsverwirrungen kommen?

Warum sollte ich keinen Kodierungsstandard aufschreiben?

Dafür gibt es einige Gründe.

1. Niemand liest Dokumentation.
2. Niemand befolgt die Dokumentation, auch wenn sie gelesen wird.
3. Niemand aktualisiert die Dokumentation, selbst wenn er sie liest und befolgt.
4. Das Schreiben einer Liste von Praktiken ist viel weniger effektiv als das Erstellen einer Kultur.

Coding - Standards sind nicht über das, was Menschen sollten tun, sondern sind über das, was sie tatsächlich tun. Wenn Personen von den Standards abweichen, sollte dies durch einen Codeüberprüfungsprozess und / oder automatisierte Tools erfasst und geändert werden.

Denken Sie daran, der springende Punkt bei der Kodierung von Standards ist es, unser Leben leichter zu machen. Sie sind eine Abkürzung für unser Gehirn, damit wir das Notwendige aus dem Wichtigen herausfiltern können. Es ist viel besser, eine Überprüfungskultur zu schaffen, um dies durchzusetzen, als sie in einem Dokument zu formalisieren.

Es gibt eine andere Interpretation. Ich glaube nicht, dass es das ist, was Onkel Bob gemeint hat, aber es lohnt sich, darüber nachzudenken.

Erfassen Sie keine Kodierungsstandards in einem Dokument. Erfassen Sie es im Code, indem Sie einen automatisierten Prozess durchführen, der überprüft, ob die Standards eingehalten werden .

Verlassen Sie sich nicht darauf, dass Personen auf ein Dokument verweisen, sondern darauf, dass sie den bereits vorhandenen Code interpretieren und herausfinden, welche Konventionen und welche Zufälle vorliegen.

Integrieren Sie so etwas wie Checkstyle in Ihren Commit-Build. Dies kann die grundlegenden Regeln wie Formatierungs- und Benennungsstandards durchsetzen und dann, anstatt sich Gedanken über den Stil zu machen, alles in einen dummen Prozess verlagern, der zumindest garantiert gründlich ist.

Wenn es darauf ankommt, definieren Sie genau, was Sie wollen, und schlagen Sie fehl, wenn es falsch ist.

Die Leute übersehen den eigentlichen Zweck eines Kodierungsstandards-Dokuments, nämlich die Beilegung von Streitigkeiten .

Die meisten Entscheidungen im Kodierungsstandard haben nur einen sehr geringen Einfluss auf die Lesbarkeit und Produktivität. Vor allem, wenn Sie den „normalen“ Stil für die Sprache übernehmen und die Sprachdesigner erkennen, dass dies Teil der Spezifikation sein sollte (z. B. Go).

Weil sie so trivial sind, können die Argumente wirklich hitzig werden und endlos weiterlaufen, was der Produktivität und dem Zusammenhalt des Teams großen Schaden zufügt. Oder Sie können Ihre Änderungshistorie durch eine endlose Neuformatierung zwischen den bevorzugten Stilen von zwei oder mehr Personen verdecken.

Ein schriftlicher Standard beendet das Argument. Manager können darauf hinweisen und Unzufriedenheit gegenüber dem Dokument abwenden. Sie können mit einem Stück Papier streiten, aber es wird Ihnen nicht zuhören.

(Siehe auch Die Tyrannei der Strukturlosigkeit )

Weil Kommentare Lügen sind .

Der Kodierungsstandard ist ein großer Kommentar zu dem, was der Code sein sollte. Der Code selbst ist die ultimative Quelle der Wahrheit. Die Wahrheit ist in diesem Fall nicht das Verhalten von Code, sondern der Stil, in dem er ausgedrückt wird. Wenn sich Ihre Standards nicht bereits in Ihrem Code widerspiegeln, haben Sie eine Menge Arbeit vor sich.

Onkel Bob sieht einen Kommentar als persönliches Versagen des Programmierers an, weil er den Zweck des Codefragments nicht mit der Programmiersprache selbst ausdrücken konnte. In ähnlicher Weise ist ein Standarddokument ein Fehler, einen kohärenten Stil in der Codebasis auszudrücken.

Neue Programmierer sollten Zeit damit verbringen, sich mit dem Code zu befassen, statt Tage damit zu verbringen, ein Dokument mit mehreren Kapiteln zu lesen (ich musste das tun, seufz).

Ein Normdokument ist keine so schlechte Idee, aber ich war in Programmiergeschäften, in denen die Pflege der Normdokumente eine Vollzeitaufgabe war. Wenn Sie ein Standarddokument aufbewahren müssen, bewahren Sie es bitte auf einer Seite auf. Aber wenn Sie bereits Code haben, sollte dann niemand in der Lage sein, dasselbe Dokument in weniger als einem Tag zusammenzustellen?

Es ist wichtig, Codestandards zu haben. Ein Dokument zu haben, das diktiert, was es ist, ist es nicht.

Warum schlägt Onkel Bob vor, Codierungsstandards nicht aufzuschreiben, wenn Sie dies vermeiden können?

Wenn Sie nach Gründen für seine Meinung fragen, haben Sie möglicherweise nur dann eine Antwort, wenn er hier eine Antwort veröffentlicht ( unsere Meinung ist jedoch irrelevant) ...

Warum sollte ich keinen Kodierungsstandard aufschreiben?

Wenn Sie fragen, ob er damit Recht hat: Lassen Sie mich (bis jetzt) ​​der einzige Unpopuläre sein, der sagt, dass Sie keinen Grund haben, es zu vermeiden.

Schreiben Sie es auf . Ich werde jedoch versuchen, meine Gründe zu erklären ...

David schlug in einem Kommentar vor, dass der Hauptpunkt von Stephens Antwort nicht darin besteht, warum Sie keine Dokumente schreiben sollten , sondern in welcher Form sie vorliegen. Wenn Richtlinien in Tools formalisiert sind (nicht nur manuelle Codeüberprüfung), kann ich zustimmen (wenn das Gesetz nichts anderes vorschreibt). Bitte beachten Sie, dass Tools leider nicht alles überprüfen können (die Berechnungstheorie ist nicht unser Freund), da sie auf eine bestimmte Übersetzungseinheit oder ein bestimmtes Paket oder auf eine beliebige Sprache, die Sie als Grenze bezeichnen, beschränkt sind .

Die Formulierung von Onkel Bob lässt mich jedoch nicht glauben, dass er darüber spricht.

Kann ich einem solchen Experten nicht zustimmen? Das tue ich für fast jeden Punkt in dem zitierten Beitrag (siehe auch den zweiten Teil dieser Antwort für Details). Lassen Sie uns versuchen zu verstehen , warum (vorausgesetzt , Sie wissen bereits, dass Code - Richtlinien nicht nur um kleinere Formatierung sind Probleme ).

• In einigen Fällen sind schriftliche Kodierungsstandards gesetzlich vorgeschrieben.
• Ich lese die Dokumentation und bin mir sicher, dass ich nicht alleine bin. Teammitglieder können sich im Laufe der Zeit ändern, Kenntnisse können nicht in einer 5- bis 10-jährigen Codebasis oder in den Köpfen von Teammitgliedern vorhanden sein. Unternehmen sollten Personen entlassen, die internen Richtlinien nicht folgen.
• Sobald die Codierungsstandards genehmigt wurden , ändern sie sich nicht mehr oft und wenn Sie dies möchten, können Sie sich darüber informieren. Wenn sich die Standards geändert haben, ist Ihre Dokumentation (im Code) nicht mehr aktuell, da Ihr gesamter Code nicht dem neuen Standard entspricht. Das Neuformatieren / Refactoring kann langsam sein, aber Sie müssen immer eine schriftliche, maßgebliche Richtlinie befolgen.
• Es ist besser, ein 5-seitiges Dokument zu lesen, als 10 / 20K LOC zu inspizieren, um eine Regel zu extrapolieren (die Sie vielleicht falsch verstehen, übrigens), kein Zweifel.
• Es ist ironisch, dass jemand, der viele Bücher über Designprinzipien und Codierungsstil geschrieben hat, vorschlägt, dass Sie keine eigenen Richtlinien schreiben sollten. Ist es dann nicht besser, wenn er uns einige Codebeispiele vorlegt? Nein, denn in den schriftlichen Richtlinien ist nicht nur festgelegt, was zu tun ist, sondern es fehlen auch zwei weitere Punkte: Was nicht zu tun ist und Gründe, es zu tun oder nicht.

"Freies selbstorganisierendes Programmieren" ist gut für einen 16-jährigen Ninja, aber Organisationen haben andere Anforderungen :

• Codequalität muss auf Unternehmensebene gewährt (und definiert) werden - darüber kann kein einzelnes Team entscheiden. Sie verfügen möglicherweise nicht einmal über die Fähigkeiten, um zu entscheiden, was besser ist (wie viele Entwickler verfügen beispielsweise über alle erforderlichen Fähigkeiten, um MISRA zu überprüfen, oder verstehen lediglich jede Regel?).
• Mitglieder können zwischen verschiedenen Teams ausgetauscht werden: Wenn alle denselben Codierungsstandards folgen, ist die Integration reibungslos und weniger fehleranfällig.
• Wenn sich ein Team selbst organisiert, entwickeln sich die Standards im Laufe der Zeit, wenn sich die Teammitglieder ändern. Sie haben dann eine riesige Codebasis, die nicht den derzeit akzeptierten Standards entspricht .

Wenn Sie vor dem Prozess über Menschen nachdenken, kann ich nur empfehlen, über TPS zu lesen: Der Mensch ist ein zentraler Bestandteil von Lean, die Abläufe sind jedoch stark formalisiert.

Natürlich ist eine kleine Organisation mit nur einem Team kann das Team läßt die Standards entscheiden zu übernehmen , aber dann muss es nach unten geschrieben werden. Hier auf Programmers.SE können Sie Beiträge von Eric Lippert lesen: Ich nehme an, wir sind uns alle einig, dass er ein erfahrener Entwickler ist. Als er für Microsoft arbeitete, musste er die schriftlichen Richtlinien einhalten (auch wenn einige Regeln falsch , nicht anwendbar oder nutzlos sein mögen zu ihm.) Was ist mit Jon Skeet? Die Google-Richtlinien sind ziemlich streng (und viele Leute stimmen ihnen nicht zu), aber er muss sich an solche Richtlinien halten. Ist es ihnen gegenüber respektlos? Nein, sie haben wahrscheinlich daran gearbeitet, solche Richtlinien zu definieren und zu verbessern. Ein Unternehmen wird nicht von einem Mitglied (oder einem Team) erstellt, und jedes Team ist keine Insel .

Beispiele

• Sie haben beschlossen, in C ++ keine Mehrfachvererbung und verschachtelten Klassen zu verwenden, da die tatsächlichen Teammitglieder dies nicht gut verstehen . Später muss jemand, der Mehrfachvererbung verwenden möchte, das gesamte 1M-LOC durchsuchen, um festzustellen, ob es jemals verwendet wurde. Es ist schlecht, denn wenn Designentscheidungen nicht dokumentiert sind, müssen Sie die gesamte Codebasis studieren, um sie zu verstehen. Und selbst dann, wenn es nicht verwendet wurde, liegt das daran, dass es gegen den Kodierungsstandard verstößt, oder ist es zulässig, aber es gab einfach keine früheren Situationen, in denen Mehrfachvererbung eine gute Anpassung war?
• In C # hatten Sie Methoden zum Bereitstellen von Standardparametern überladen, da Ihre Codebasis gestartet wurde, als optionale Parameter in C # nicht verfügbar waren. Dann haben Sie sich geändert und Sie haben begonnen, sie zu verwenden (indem Sie den alten Code überarbeitet haben, um sie jedes Mal zu verwenden, wenn Sie solche Funktionen ändern mussten). Auch später haben Sie festgestellt, dass optionale Parameter schlecht sind, und Sie vermeiden, sie zu verwenden. Was ist die Regel , die Ihnen Ihr Code sagt? Es ist schlecht, weil sich Standard weiterentwickelt, aber die Codebasis langsamer entwickelt, und wenn es Ihre Dokumentation ist, dann stecken Sie in Schwierigkeiten.
• Jon wechselte von Team A zu Team B. Jon muss einen neuen Standard lernen ; Während des Lernens wird er wahrscheinlich subtilere Fehler einführen (oder, wenn Sie Glück haben, nehmen Sie sich einfach viel Zeit, um den vorhandenen Code zu verstehen und die Codeüberprüfung zu verlängern).
• Team A wechselt zu einer Codebasis, die zuvor Team B gehört. Es gelten völlig andere Codierungsstandards. Umschreiben? Anpassen? Mischen? Alle sind gleich schlecht.

Onkel Bob

Lassen Sie sie in den ersten paar Iterationen weiterentwickeln.

Richtig, bis Sie keinen Standard haben und Ihre Organisation Ihnen die Aufgabe zugewiesen hat , einen zu erstellen .

Lassen Sie sie teamspezifisch statt firmenspezifisch sein.

Nein, aus allen oben genannten Gründen. Selbst wenn Sie denken, nur die Code-Formatierung zu formalisieren (die am wenigsten nützliche Sache, die Sie vielleicht formalisieren möchten), habe ich immer noch die Erinnerung an endlose (und nutzlose) Kriege um die Formatierung. Ich möchte sie nicht immer wieder leben, sondern ein für alle Mal einstellen.

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.

Nein, aus den oben erläuterten Gründen (natürlich, es sei denn, Sie ändern Ihren gesamten Code auf einmal, wenn sich die Richtlinien ändern). Möchten Sie Ihren Code unverändert lassen? Wie überprüfen Sie die Codebasis, um die aktuellen Richtlinien zu verstehen ? Suchen Sie nach dem Alter der Dateien und passen Sie Ihren Codierungsstil an das Alter der Quelldateien an?

Legisliere kein gutes Design. (zB sag den Leuten nicht, dass sie goto nicht benutzen sollen)

Richtig, Richtlinien müssen kurz sein, sonst wird sie niemand lesen. Wiederholen Sie nicht das Offensichtliche.

Stellen Sie sicher, dass jeder weiß, dass es bei dem Standard um Kommunikation geht, und um nichts anderes.

Bei einem guten Standard geht es nicht nur um Qualität, es sei denn, Sie möchten einen Standard nur für kleinere Details haben.

Bringen Sie das Team nach den ersten Iterationen zusammen, um zu entscheiden.

Sehen Sie sich den ersten Punkt an und vergessen Sie nicht, dass ein Codierungsstandard in der Regel ein Prozess ist, dessen Entwicklung und Weiterentwicklung viele Jahre in Anspruch nahm: wenige Iterationen, möglicherweise mit Nachwuchsentwicklern? "Ja wirklich?" Möchten Sie sich auf das Gedächtnis eines älteren Mitglieds (falls vorhanden) verlassen?

Drei Notizen:

• Meiner Meinung nach sind die Nachteile bei einigen Sprachen größer als bei anderen. In C ++ ist beispielsweise ein Unternehmensstandard sogar noch wichtiger als in Java.
• Diese Überlegung trifft möglicherweise nicht ganz zu (und die Gründe für Onkel Bob sind möglicherweise weniger extrem ), wenn Sie in einem sehr kleinen Unternehmen arbeiten, in dem Sie nur ein kleines Team haben.
• Sie werden eingestellt (als Team) und Sie werden alleine mit einem neuen Projekt arbeiten, dann werden Sie es vergessen und weitermachen. In diesem Fall ist es Ihnen vielleicht egal (aber Ihr Arbeitgeber sollte ...)

1. Um nützlich zu sein, darf ein Kodierungsstandard nicht über inhaltliche Angelegenheiten sprechen. nur Stilfragen. Es sollten nur die Dinge angegeben werden, die willkürlich und mehrdeutig sind. zB Platzierung der Klammern, Einrückungstiefe, Leerzeichen gegenüber Tabulatoren, Namenskonventionen usw.
2. Stilfragen sind lokal und nicht global. Jedes Team sollte seinen eigenen, auf seine Aufgabe und Persönlichkeit abgestimmten Stil annehmen. Dies hält die Standards einfach und leicht. Unternehmensstandards werden mit allen möglichen Überlegungen, Konfigurationen und Ausnahmen überlastet.
3. Innerhalb eines Teams besteht der einzige Grund, ein separates Dokument im Codestil zu schreiben, darin, dass der vom Team erstellte Code nicht dem Standard entspricht. In diesem Fall haben Sie keinen Standard. Um effektiv zu sein, sollte der Standard durch den Code selbst ausgedrückt werden. In diesem Fall ist kein separates Dokument erforderlich.
4. In älteren Systemen ändern sich Teams und Stile im Laufe der Zeit. Daran ist nichts auszusetzen. Alter Code hat einen älteren Stil. Neuerer Code hat einen neueren Stil. Das Team sollte sich der Stile und ihres Alters bewusst sein. Wann immer neuer Code geschrieben wird, sollte er im neuen Stil sein, egal wo im Code er sich befindet.

Warum sollte ich keinen Kodierungsstandard aufschreiben?

Dafür gibt es viele Gründe. Hier sind einige Überlegungen:

1. Wie viel Zeit verbringen die Leute damit, Codestandards zu "lernen", nur um viel Zeit in das gesamte Team zu investieren, um Codestandards zu überprüfen, zu diskutieren, zu dokumentieren, zu überarbeiten usw. Das ist so, als würde man ständig über sein "Mitarbeiterhandbuch" diskutieren - wie oft steht es dann auf der Tagesordnung eines Teammeetings?

2. Wenn ein Projekt defundiert / zurückgestellt / etc. dann können die wenigen Menschen, die normalerweise bleiben, die Standards nicht weiter einhalten (oder haben sie vielleicht nicht einmal gelesen). Das nächste, was Sie wissen, war die ganze Anstrengung, den Code sauber zu halten, sowieso ziemlich umsonst.

3. Wenn das Projekt ins Stocken gerät oder ein neuer Interessent hinzukommt, wird die Person wahrscheinlich die vorherigen Regeln völlig ignorieren und es auf eine neue Art und Weise tun wollen. Was hat die Kodifizierung von Standards gebracht?

Sie sollten unbedingt # 6 lesen:

Bringen Sie das Team nach den ersten Iterationen zusammen, um zu entscheiden.

Mit anderen Worten, wenn es Zeit ist, ein Projekt zu starten, gehen Sie einfach eine Weile mit dem Fluss. Besprechen Sie dann die allgemeinen Regeln für Codierungsstandards, die das aktuelle Team verwendet - und befolgen Sie diese im Wesentlichen. Auf diese Weise maximieren Sie den Aufwand für die Produktverbesserung und minimieren gleichzeitig den Aufwand für das Schreiben, Überprüfen und Dokumentieren des "syntaktischen Zuckers", der für das Abrufen von ausführbarem Code aufgewendet wurde.

Nur sehr wenige Teams profitieren von Kodierungsstandards. Normalerweise ist "Lesbarkeit" viel zu vage - und die meisten Entwickler profitieren nicht sehr von genauen Regeln für Abstände, neue Zeilen usw., aber Sie können ständige Ärger für Entwickler vermeiden , indem Sie mindestens ein paar Regeln haben.

Eine andere Antwort, die meines Erachtens nicht klar genug formuliert wurde, ist, dass die Leute sich nicht blind an die Regeln halten. Dies bedeutet, dass die Leute sich tatsächliche Begründungen für ihre Entwurfsentscheidungen und Kodierungskonventionen einfallen lassen müssen , anstatt nur von der Tatsache abhängig zu sein, dass sie zur Rechtfertigung niedergeschrieben wurden.

Erstens, soweit ich weiß, ist Onkel Bob ein Java-Mensch. Dies ist sehr wichtig, um zu verstehen, was er sagt.

Wenn ich in einem Java- oder C # -Team arbeite und der aktuelle Code von erfahrenen Entwicklern geschrieben wurde, fällt es mir leicht, den Codierungsstil zu verstehen und mit ihm Schritt zu halten. Wenn ich nicht dazu bereit bin, war ich vielleicht nicht die richtige Person für den Job ... Wenn es keine Codeüberprüfung oder Paarprogrammierung gibt, die mich abholen, wenn ich mich nicht an den Stil halte, dann hat das Unternehmen eine Größeres Problem als die Art und Weise, wie ich Mitgliedsfelder benenne!

Sowohl Java als auch C # sowie die meisten modernen Sprachen wurden so definiert, dass es für einen Programmierer nur wenige "einfache" Fallen gibt.

Als ich jedoch mit dem Programmieren anfing, verwendete ich C (und später C ++). In C können Sie Code wie schreiben

if (a = 3);
{
   /* spend a long time debugging this */
}

Der Compiler gibt keinen Fehler aus und das ist beim Lesen von viel Code schwer zu erkennen. Wenn Sie jedoch schreiben:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Der Compiler gibt einen Fehler aus und ich kann den Code leicht auf ändern 3 == a. Wenn der Codierungsstandard keine =Verwendung innerhalb einer ifBedingung oder einer "leeren ifAnweisung" zulässt , kann als Teil des Build-Systems ein Code-Checker verwendet werden, um diesen Fehler zu verfolgen.

Meine Ansichten zu Codierungsstandards änderten sich stark, als ich mich von C / C ++ entfernte: Ich mochte Codierungsstandards, die strikt durchgesetzt wurden und viele Seiten lang waren. Ich denke jetzt müssen Sie nur noch die verwendeten Tools auflisten und eine informelle Einigung zwischen den ursprünglichen Teammitgliedern über einige Namenskonventionen erzielen. Wir leben nicht mehr in einer Welt von Teams mit über 30 Entwicklern, die Anwendungen in C / C ++ schreiben ...

Es gibt einen Grund, warum ich JScript nie mochte, und ich denke, TypeScript ist das Beste, was der Webentwicklung seit Jahren passieren kann. Ich gehe davon aus, dass Web-UI-Entwickler aufgrund der fehlerhaften Gestaltung von HTML / CSS / JScript usw. weiterhin Codierungsstandards benötigen.

Wenn die Quelle der selbstdokumentierende Codierungsstandard ist, bedeutet dies zwei Dinge.

1. Die Mitarbeiter müssen die Codebasis konsultieren und überprüfen, um kompetente Mitarbeiter zu werden. Das ist unglaublich wichtig. Das Lesen von Codierungsrichtlinien ist eine Zeitverschwendung im Vergleich zum Eintauchen in die Codebasis.
2. Es räumt ein, dass geringfügige Unterschiede unwichtig sind. Es ist wichtig, die Grundprinzipien zu vereinbaren und zu verstehen. Die Aufrechterhaltung eines einheitlichen Stils wird nicht als l'art pour l'art verfolgt. Es erlaubt unkreativen Nitpickern nicht, andere Menschen zu ärgern und abzulenken. Es geht darum, die Kommunikation durch Code in einem Team zu erleichtern.

Ein häufig aktualisiertes und gut geschriebenes Dokument mit Codestandards kann sehr nützlich sein. In der Regel ist dies jedoch nicht der Fall. Das Standarddokument spiegelt nicht die tatsächlichen Kodierungsstandards des Unternehmens wider, da es sehr schwierig ist, ein gutes Standarddokument zu erstellen und es noch schwieriger zu halten, es auf dem neuesten Stand zu halten.

Anstatt ein schlechtes und irreführendes Kodierungsstandarddokument zu haben, ist es besser, keines zu haben und den Code selbst diese Standards darstellen zu lassen. In jedem Fall ist es wichtig, die Standards im Code anzuwenden, und dies erfordert viel mehr als nur ein Dokument. Motivation, Prozesse, Schulungen, Tools usw. sind viel wichtiger.

Eine sehr wichtige Sache, die nicht klar genug formuliert wurde, ist, dass Codierungsstandards wie Sprache sind: Sie entwickeln sich weiter. Ein schriftlicher Kodierungsstandard steht dem im Weg, und wenn nicht, ist er ständig veraltet und unbrauchbar.

Es ist nicht so schlimm, keinen festgelegten Kodierungsstandard zu haben. Wenn Sie beim Einchecken Peer-Reviews durchführen, wird immer dann, wenn etwas in das Repository gelangt, das nicht dem Kodierungsstandard entspricht, 2 Personen darüber nachgedacht * und festgestellt, dass der Nutzen dieser Variante die Inkonsistenz mit dem Rest des Codes überwiegt.

Das Fehlen eines schriftlich niedergelegten Standards beseitigt auch den bürokratischen Aufwand, der ein Team eines Unternehmens daran hindert, eine neue Variante des Kodierungsstandards für ein neues Projekt auszuprobieren, entweder weil sie etwas ausprobieren möchten oder weil ein anderer Standard praktische Anwendungen hat auf einigen der automatisierten Tools, die sie verwenden.

Das Aufschreiben einer Norm hat die Tendenz, mehr Flexibilität zu verlieren als ursprünglich beabsichtigt, und gleichzeitig eine Menge Zeit in Anspruch zu nehmen, die für andere Aufgaben aufgewendet werden könnte. Ich sage nicht, dass Sie niemals Codierungsstandards aufschreiben sollten. Geschriebene Standards haben sicherlich ihre Vorteile, insbesondere wenn Teams, die an verschiedenen Standorten arbeiten, auf derselben Codebasis arbeiten.

Stark verwandt: Evolution der Codierungsstandards, wie gehen Sie damit um?

* Wenn die Leute beim Einchecken beim Überprüfen des Codes nicht nachdenken, sind Ihre Probleme viel größer als nur die Codierungsstandards.

Sie zu ändern, wird zu einer großen Hürde, und die Menschen halten sich sicher an den Wortlaut des Gesetzes, anstatt den Verstand zu beschäftigen und das Richtige zu tun.

Es wird einen Tag geben, an dem ein Teil des Standards nicht hilfreich ist und den Code verschlimmert. Einige Leute halten sich an den Standard, weil er aufgeschrieben und sicher ist und weil Regeln befolgt werden müssen. Leute, die guten Code schreiben wollen, anstatt standardkonformen Code zu schreiben, werden frustriert und verärgert sein. Es wird Argumente und Meinungsverschiedenheiten geben, während es, wenn der Standard nicht aufgeschrieben würde, zu Erkundungen und Diskussionen kommen würde.

Ich denke, viele Posts hier verwechseln den Codierungsstandard mit dem Styleguide .

Stellen Sie sicher, dass Module, die von verschiedenen Teams entwickelt wurden, die gleichen Compiler-Optionen haben und ABI eine andere Art von Sache ist als die Anzahl der eingerückten Leerzeichen.

Dinge wie die ordnungsgemäße Strukturierung von #include-Dateien und die Vermeidung einer Verschmutzung des globalen Namespace in einer Header-Datei sollten dokumentiert werden, damit sie bei der Erstcodierung und Codeüberprüfung als Prüfliste verwendet werden können.

Insbesondere "Verwenden Sie XXX nicht, da dies zu Kompatibilitätsproblemen mit YYY führt" wird im folgenden Code nicht als Beispiel aufgeführt, da es nicht vorhanden ist. So lassen Sie den Code der Art und Weise , werden die Standards erfasst werden könnte für einige Arten von Standards unklar oder ganz fehlen, und so kann dies kein universeller Plan.

Etwas ernsthaft Durchdringendes und Wichtiges wie die Nichtverwendung von Ausnahmen oder die Nichtverwendung newin bestimmten eingebetteten Systemen kann nicht einfach als allgemeines Kulturwissen gelten, da "Information ist (nur) kulturell" den Grundprinzipien von Fertigungsstandards wie ISO-9000 widerspricht Entwickler dieser eingebetteten Systeme verwenden (z. B. für Automobilanwendungen). Diese wichtigen Dinge müssen dokumentiert, abgezeichnet und auf formelle Weise abgelegt werden.

Dies gilt jedoch für die Codierung und nicht für den Stil .

Die Erfinder von C und C ++ zeigen beispielhaft die Verwendung von Kleinbuchstaben und nicht CaMelCaSe. Warum folgen so viele Entwickler nicht dem impliziten Beispiel aus der Quelle? Sollte der Stil der Standardbibliothek und der kanonischen Lehrmaterialien nicht der implizite Stil sein, dem man folgen sollte?

Inzwischen Menschen tun dem Beispiel der Standard - Bibliothek - Header für Dinge folgen , die nicht kopiert werden sollen, wie die Verwendung von __UglyNamen für den Makroparameter und die gehören nicht-Wiederholungsmuster - Datei.

Daher wird es oft nicht als wichtig erachtet, Dinge zu haben, oder umgekehrt, Beispiele zu haben, ist möglicherweise nicht klar, was im Projektcode nicht beachtet werden sollte . Beide sind Gegenbeispiele zu der These, dass "Stil" (oder Kodierungskonventionen) am besten implizit bleiben.