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


145

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

  1. 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?


47
Hmm. Ich versuche mir vorzustellen, wie das in einem großen multinationalen Unternehmen mit Hunderten von Entwicklern und einer jahrzehntelangen Codebasis funktionieren würde.
Matthew James Briggs

31
@MatthewJamesBriggs: Es funktioniert mindestens so gut wie ein abgeschriebener Standard, den die meisten Entwickler ignorieren oder der zu dem Zeitpunkt, als der Code ursprünglich geschrieben wurde, einen anderen Inhalt hatte.
Doc Brown

7
@MatthewJamesBriggs: einverstanden. Der Styleguide sollte genügend Informationen enthalten, um frühere Konventionen zu erkennen, die mittlerweile veraltet sind. Andernfalls wird die Kultur des "Kopierens des vorhandenen Stils" einen 10 Jahre alten Horror finden, der wieder auferstehen kann. Wenn sich versehentlich Cliquen bilden, die unterschiedliche und inkompatible Muster für die Ableitung des offiziellen Stils verwenden, gibt der schriftliche Stilleitfaden an, welcher von ihnen richtig ist (oder im Idealfall verhindert, dass sich die Cliquen überhaupt bilden). Und wenn einige Ihrer Hunderte von Entwicklern keine Dokumente lesen, können Sie sie in einem großen Unternehmen einfach wegen grober Muppetry entlassen.
Steve Jessop

14
Um fair zu sein, sagte Bob auch, dass Sie keinen unternehmensweiten Kodierungsstandard haben sollten, weder geschrieben noch ungeschrieben. Vielmehr sollte jedes Team / jede Clique ein eigenes entwickeln.
Steve Jessop

37
Anstatt ein Dokument zu schreiben, das niemand lesen wird, sollten Sie einen Linter verwenden, der den Code auf eine bestimmte Weise erzwingt. Wenn es Teil Ihres Entwicklungsprozesses ist, ist es unvermeidlich.
Seiyria

Antworten:


256

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.


11
Und wenn Sie Dinge erzwingen möchten, sollten Sie einen Build-Prozessschritt verwenden, der dies erzwingt, und keinen diesbezüglichen Styleguide.
Wayne Werner

31
Haben Sie wirklich kein Standarddokument, sondern schreien die Leute in den ersten Wochen bei jeder Codeüberprüfung an? Dies scheint, als würden Sie im Grunde erwarten, dass Anfänger Ihre Coding-Style-Guides zurückentwickeln. Oder ist das eher eine Hypothese "Ich denke, das hat er gemeint"? Wenn es um automatische Tools zur Durchsetzung dieser Regeln geht, ist dies unabdingbar. Aber ich möchte nicht mühsam die Regeln herausfinden müssen.
Voo

13
@Voo, warum musst du während einer Codeüberprüfung schreien, wenn ein Problem auftritt?
Jaap

20
@Jaap Ich dachte die Übertreibung sei offensichtlich .. anscheinend nicht. Nein, die Leute nicht anzuschreien, sondern ihnen zu sagen, dass sie zurückgehen und all die Dinge reparieren müssen, gegen die sie verstoßen haben, weil sie es nicht besser wissen konnten.
Voo

5
@Voo: Sie müssen keine Coding-Style-Guides rückentwickeln. Die Konventionen sollten bei der Betrachtung des vorhandenen Codes offensichtlich sein . Alles, was nicht sofort ins Auge springt, ist entweder ungewöhnlich oder nicht einmal fixiert. Für den Fall, dass es wirklich wichtige Regeln gibt, dass etwas selten vorkommt, kann es sich lohnen, diese mit den neuen Entwicklern zu besprechen, wenn sie solche Codes schreiben müssen. Kommunikation kann nicht überschätzt werden.
Holger

112

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.


6
Eigentlich vermute ich, dass so etwas zumindest Teil von Onkel Bobs Argumentation für den Vorschlag war. Die Automatisierung von Codierungsstandards geht mit automatisierten Tests
Jules

10
Es könnte erwähnenswert sein, Regel 6 zu erwähnen: After the first few iterations, get the team together to decide.Mit Regel 3 scheint er keinen Kodierungsstandard zu befürworten, aber wenn er alle Regeln zusammen betrachtet und vor allem # 6, scheint er wirklich zu sagen: "Tu es nicht Erzwingen Sie zuerst einen Kodierungsstandard. Lassen Sie ihn sich organisch entwickeln und setzen Sie sich nach einer Weile mit Ihrem Team zusammen, um die Details zu klären. " Was sich sehr von "Nicht formalisieren" unterscheidet (was die Essenz vieler Antworten zu sein scheint).
Shaz

Wenn Sie die Artikel lesen, werden Sie sicher feststellen, dass dies nicht das ist, was er gemeint hat, zum Beispiel sollte Ihnen dieser allein etwas sagen: 2. Lassen Sie sie teamspezifisch statt firmenspezifisch sein.
Bill K

Beachten Sie, dass ich die Frage "Warum sollte ich keinen Kodierungsstandard aufschreiben?" Beantworte - nicht "Was hat Onkel Bob gemeint?". Das mag dem Titel der Frage zuwiderlaufen, nicht aber ihrem Geist.
Tom Johnson

Beachten Sie, dass ein automatisiertes Codierungsformatsystem, das keine Escape-Klausel enthält (in der ich es für einen Codeabschnitt deaktivieren kann), mit ziemlicher Sicherheit irgendwann Malware sein wird.
Yakk

66

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 )


19
Dies ist unglaublich wichtig für Teams, die sich mit Legacy-Code befassen. Vor allem, wenn Sie von Code, der einer Reihe von Standards folgt (oder keine Standards befolgt), zu einer anderen wechseln. Ohne eine zu verweisende Richtlinie ist es unmöglich zu sagen, welchem ​​Codestil zu folgen ist, wenn bereits mehrere Stile in der Codebasis vorhanden sind. Ich denke, der Rat, Standards nicht aufzuschreiben, ist für sehr kleine Teams gedacht, die an Projekten auf der grünen Wiese ohne Risikoumsätze arbeiten - meiner Erfahrung nach ein sehr seltener Fall.
Donnerstag,

4
Es ist viel wichtiger, einem Standard zuzustimmen, als dem tatsächlichen Inhalt des Standards. Sie können sich an fast jeden Stil gewöhnen, wenn Sie lange genug damit arbeiten.
Mark Ransom

3
Über Kleinigkeiten zu streiten ist ein Zeichen von Inkompetenz, IMHO. Die Beilegung des konkreten Streits wird das zugrunde liegende Problem nicht lösen.
Jørgen Fogh

1
Ja, die Beilegung von Konflikten und die Aufrechterhaltung einer sauberen Änderungshistorie sind enorm, insbesondere wenn Sie eine Mischung aus OCD- und nicht so OCD-Entwicklern in Ihrem Team haben. Ich habe jedoch festgestellt, dass geschriebene Standards weitaus weniger effektive Schiedsrichter sind als automatisierte Tools wie StyleCop, die das Gesetz festlegen, ohne es persönlich zu machen oder die Zeit der Manager zu verschwenden.
Eric Hirst

12
"Streiten über Trivialitäten ist ein Zeichen von Inkompetenz" - ich wünschte, dies wäre in der Softwareentwicklung der Fall ... Ich fürchte, einige sehr, sehr kompetente (zumindest technisch) Entwickler sind genau die Leute, die am liebsten über Trivialitäten streiten. Hölle, es ist ihr Nationalsport. "Unendlich sind die Argumente der Magier" -Ursula Le Guin
Spike0xff

21

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.


22
Ich habe tatsächlich die jahrzehntelange Codebasis mit der Richtlinie "Keine Kommentare" erlebt. Es regt zwar sehr lange beschreibende Methodennamen an, aber es ist absolut schrecklich, Absichten zu erfassen, Gründe , Dinge nicht zu tun, und wir kommen nur damit davon, wenn einer der ursprünglichen Autoren noch bei uns ist.
pjc50

7
+1 "Es ist wichtig, Codestandards zu haben. Ein Dokument, das diktiert, was es ist, ist es nicht." Gut und prägnant ausgedrückt.
David

4
@ pjc50 Ich habe noch nie gehört, dass Onkel Bob zu einer Politik ohne Kommentar ermutigt hat. Er lehrt nicht, dass Sie niemals kommentieren sollten. Er lehrt, dass Sie sich schlecht fühlen sollten, wenn Sie feststellen, dass Sie es tun müssen, um verstanden zu werden. Nicht kommentiert nicht lesbar <kommentiert nicht lesbar <lesbarer Code, der keine Kommentare benötigt. Beachten Sie, dass die von Ihnen erwähnten Kommentare vollständig von der Funktionsweise des Codes entkoppelt sind. Standarddokumente können sich in eine Checkliste verwandeln, die bei einer Codeüberprüfung abgehakt wird. Was wichtig ist, ist nicht, dass Sie alle Ihre Zecken bekommen. Es ist so, dass die Leute am Tisch Ihren Code verstehen.
candied_orange

3
"Neue Programmierer sollten Zeit damit verbringen, sich mit dem Code zu befassen, statt Tage damit zu verbringen, ein Dokument mit mehreren Kapiteln zu lesen." Keine Ahnung, welchen Codierungsleitfäden Sie folgen, aber der C ++ - Stilleitfaden von Google kann problemlos in weniger als einer Stunde gelesen werden und ist viel einfacher herauszufinden, als den bevorzugten Stil auf der Grundlage des vorhandenen Codes (der für mich schrecklich klingt) rückentwickeln zu müssen. Das gleiche gilt für jeden anderen Styleguide, den ich jemals gelesen habe.
Voo

5
@CandiedOrange: Oft sind die nützlichsten Kommentare die, die beschreiben, warum bestimmte Dinge nicht getan wurden [da zukünftige Programmierer ohne solche Kommentare möglicherweise Zeit damit verschwenden, scheinbar offensichtliche "Verbesserungen" in dieser Runde zu implementieren und später zurückzuziehen nicht umsetzbar sein]. Solange man mit Variablennamen nicht wirklich verrückt wird, gibt es keine Möglichkeit, dass selbst der am besten lesbare Code diese Informationen erfasst.
Supercat

16

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 ...)

5
Ich habe dies abgelehnt, weil ich der Meinung bin, dass die Antwort nicht zum Thema der Frage gehört, weshalb Sie (und insbesondere Onkel Bob) keinen Kodierungsstandard schreiben würden , und nicht, warum Sie sollten. Ich denke, jeder versteht die Pluspunkte eines schriftlichen Standards, aber die Nachteile sind schwerer zu bestimmen, und wenn ein angesehener Branchen-Senior eine Position herausbringt, die der in der Branche üblichen Praxis widerspricht, sollte geprüft werden, warum dies mit Sicherheit eine lohnende Sache ist.
Jules

5
@gnat danke, ich brauche keine Upvotes für Off-Topic-Posts, nicht "Warum hat Herr X Y getan?" Off-Topic in diesem Fall? Wir kennen seine Gründe nicht und er hat sie nicht erklärt, sollte die Frage dann nicht als Off-Topic geschlossen werden? Wie würden Sie diese Frage beantworten? Zufällige Gründe erfinden oder die Prämisse als falsch bezeichnen?
Adriano Repetti

1
@AdrianoRepetti - Onkel Bob hat im Laufe der Jahre viel erklärt, daher ist es vernünftig anzunehmen, dass jemand einen Einblick in seine Denkweise hat, aber Sie haben Recht, wenn die direkte Interpretation von Onkel Bob erforderlich ist.
JeffO

3
@ Jeff Ja, wenn es um die Frage geht, warum er so denkt, dann ist die Antwort nur eine Vermutung. Wenn die Frage ist "ist es richtig?" dann ist meine persönliche antwort d *** absolut nein.
Adriano Repetti

1
"Als er für Microsoft arbeitete, musste er sich an die schriftlichen Richtlinien halten" - wetten Sie, das habe ich getan. Und natürlich haben wir FXCop und StyleCop verwendet, um zu verhindern, dass einige schlechte Patterns jemals eingecheckt werden.
Eric Lippert

12
  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.

Ich habe einige Ratlosigkeit: 1) um nützlich zu sein, sollte ein Codierungsstandard nicht nur über Formatierung (Angelegenheit heiliger Kriege, aber leicht verständlicher Code) sprechen, sondern Konstrukte, die Codierungsmuster vermeiden (um häufige Fehler zu vermeiden, nicht leicht verständliche Sprache) Funktionen) und Sicherheitsfragen. Dies sind Codierungsrichtlinien (nützlicher als Formatierungsprobleme). 2) Angesichts der Prämisse von Punkt 1 geht es nicht um Persönlichkeit (aber es können Aufgaben sein ), Sie können einen schlanken Unternehmensstandard haben, es ist Ihre eigene Pflicht, ihn schlank zu machen.
Adriano Repetti

3) Code kann Ihnen sagen, was Sie tun sollen, aber er kann nicht vermitteln, was Sie nicht tun sollten (es sei denn, Sie möchten die gesamte Codebasis studieren und selbst in diesem Fall ... mussten Sie einfach kein X-Konstrukt verwenden oder es ist ein Nein-Nein?) Eine andere wichtige Sache ist die Begründung: warum nicht? und warum ja? Dinge können sich im Laufe der Zeit ändern, aber woher wissen Sie, ob die ursprünglichen Prämissen noch gültig sind? 4) und wenn Sie ein neues Teammitglied sind und neuen Code schreiben ... studieren Sie die Codebasis mit demselben Alter, um diesen Codierungsstil beizubehalten? Am Tag, nachdem Sie zu einer anderen neueren Komponente gewechselt sind und die Codebasis erneut studiert haben (Filtern nach Erstellungsdatum?)
Adriano Repetti,

BTW , wenn stattdessen vorschlagen , dass Sie nicht nur den Code zu tun aufschreiben Formatierungen dann ich kann zustimmen (na ja, eigentlich nicht , aber mit nicht so starke Gründe neben Erinnerungen an endlose und nutzlose Diskussionen , die unweigerlich jedes Mal entstehen - und die eine Unternehmensrichtlinie Dies wird ein für alle Mal vermieden. Sie sollten dies jedoch klarstellen oder die Leute werden Ihre Worte zu wörtlich interpretieren (siehe die meisten Antworten + Kommentare hier). Auch dieser Punkt über "goto" ist in diesem Sinne etwas irreführend (IMO)
Adriano Repetti

4

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.


4

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.


4

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.


4
"Der Compiler gibt keinen Fehler aus" Die meisten modernen C- und C ++ - Compiler unterstützen das Melden eines solchen Verhaltens mit Warnungen oder, falls gewünscht, mit vollständigen Fehlern. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB

2
"Erstens, soweit ich weiß, dass Onkel Bob eine Java-Person ist, ist dies sehr wichtig, um zu verstehen, was er sagt", das ist nicht wahr, Onkel Bob hat fantastische Artikel über C ++ geschrieben und auf jeden Fall auch mehrere Jahre mit C gearbeitet.
Alessandro Teruzzi

@JAB, Glücklicherweise wurde C / C ++ vor langer Zeit nicht mehr für neue "Geschäftsanwendungen" verwendet (z. B. vor modernen C / C ++ - Compilern) und wird jetzt hauptsächlich von C / C ++ - Experten und nicht mehr von UI-Experten verwendet (MFC) zum Beispiel.
Ian

1
@AlessandroTeruzzi Ein Komponententest zeigt an, dass eine Methode fehlschlägt. Warum dies fehlschlägt, ist eine andere Sache - selbst wenn Sie Unit-Tests für eine Methode mit dieser Art von Code hätten, würde es Ihnen wirklich schwer fallen, herauszufinden, was falsch läuft. C ++ ist eine der bestrafendsten Sprachen zum Debuggen.
T. Sar

2
Ich denke, es gibt hier ein Missverständnis, Sie können nicht einen einzigen Satz von UncleBob nehmen und ihn isoliert analysieren. Wenn Sie SOLID-Software mit kleinen Klassen, kurzer Methode und kugelsicherer Einheitentestabdeckung haben, ist der Kodierungsstandard überflüssig. Wenn Sie schwachen Code, eine große Benutzeroberfläche, große Funktionen und eine geringe Abdeckung haben, kann Ihnen der Codierungsstandard einige Vorteile bringen. UncleBob schlägt jedoch nicht vor, keinen zu haben, sondern ihn durch Zusammenarbeit und Refactoring verbal zu verbreiten (schwachen Code aus der Quellbasis entfernen). Machen Sie Ihren Code zum lebenden Kodierungsstandard.
Alessandro Teruzzi

3

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.

2

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.


2

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.


1

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.


0

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.