Was sollten Kodierungsrichtlinien tun, und gibt es gute Beispiele für Richtlinien? [geschlossen]

Für die Codierung von Standards gibt es im Allgemeinen drei Zwecke:

• Reduziere die Wahrscheinlichkeit von Fehlern
• Reduzieren Sie den Zeitaufwand für die Analyse von Code, der von jemand anderem geschrieben wurde
• Geben Sie jemandem eine Powertrip

Offensichtlich ist das dritte eine Verschwendung der Zeit aller anderen, aber Sie müssen es in Betracht ziehen, insbesondere damit Sie nicht diesen Weg gehen.

Nachdem ich das gesagt habe, gibt es einige eindeutige Dinge, die ich bemerkt habe:

• Erzwingen konsistente Leerraumnutzung. Tabs, 2 Leerzeichen, 4 Leerzeichen, spielt keine Rolle. Halten Sie es konsistent, so dass die Einrückungsebenen von Leuten, die verschiedene Editoren verwenden, nicht vermasselt werden. Ich habe Fehler gesehen, weil Wartungsprogrammierer die Verschachtelungsebene eines Codeblocks falsch interpretiert haben.
• Erzwingen Sie konsistente Protokollierungsmethoden. Es ist ein enormer Aufwand für die Supportmitarbeiter, wenn sie nicht in der Lage sind, Logs zu überfliegen, da das Modul jedes Moduls aus verschiedenen Gründen protokolliert und jeder eine andere Definition von Info vs. Warnung vs. Fehler hat.
• Erzwingen Sie eine konsistente Fehlerbehandlung. Wenn Modul A Ausnahmen auslöst, gibt Modul B Fehlercodes zurück, und Modul C protokolliert einfach und geht weiter, es wird ein Schmerz sein, sie zu integrieren, ohne dass ein Fehler durch die Risse geht.
• Versuchen Sie, Kleinigkeiten wie die Platzierung von geschweiften Klammern zu vermeiden. Das wird viele Leute dazu bringen, sich über ihren Lieblingsstil zu streiten, und am Ende hat das wirklich keinen großen Einfluss auf die Lesbarkeit von Code. Auf der anderen Seite kann die Durchsetzung der Präsenz von Klammern einen Unterschied machen.
• Wenn Sie unterschiedliche Codebasen integrieren, sollten Sie nicht versucht sein, die Namenskonventionen für alle Variablen so zu ändern, dass sie dem goldenen Standard entsprechen. Möglicherweise haben Sie einen Standard für die Vorwärtsbewegung, aber am wichtigsten ist, dass alle lokalisierten Standards, die bereits existieren, konsistent beibehalten werden. Wenn ein Modul m_member verwendet, sollte ein Wartungsprogrammierer m_member2 verwenden und keinen anderen Standard anwenden (z. B. member2_ oder m_lpcstrMember2 oder was auch immer). Lokale Konsistenz ist König.
• Dateisystemlayout ist wichtig. Halten Sie es konsistent. Erleichtern Sie es jemandem, in eine Quelldatenbank der Bibliothek zu springen und sofort zu wissen, wo sich die Header, das Makefile, die Quellen usw. befinden. Wenn Sie mit Java oder Python arbeiten, ist dies kein Problem, da das Paketsystem dies erzwingt. Wenn Sie mit C, C ++ oder einer Vielzahl anderer Skriptsprachen arbeiten, müssen Sie selbst ein Standardlayout erstellen und dabei bleiben.
• Schwitz nicht das kleine Zeug. Variablennamenskonventionen, Leerzeichen zwischen Klammern oder Schlüsselwörter oder Funktionsnamen ... das meiste ist egal, weil es die Wahrscheinlichkeit eines Fehlers nicht verringert. Jede Regel, die Sie festlegen, sollte eine konkrete Begründung haben, und Sie sollten keine Angst haben, sie zu ändern oder zu entfernen, wenn Sie feststellen, dass sie mehr Kummer verursacht, als sie wert ist.
• Erzwinge keine unnötigen Kommentarblöcke überall. Sie werden als Verschwendung enden, und die meisten Kommentare werden besser im Code selbst ausgedrückt (zum Beispiel als Variablen- oder Funktionsnamen).

Schließlich ist es am wichtigsten, regelmäßige Code-Reviews zwischen Kollegen zu haben. Ermutigen Sie die Leute zu sprechen, wenn sie einen "Code-Geruch" sehen. Stellen Sie außerdem sicher, dass die Leute erkennen, dass konstruktive Code-Kritik nicht als persönliche Information gedacht ist - die Quelle wird von jedem im Team geteilt, es gehört nicht nur dem ursprünglichen Autor. Nach meiner Erfahrung waren die abscheulichsten Probleme Entwurfsprobleme, die durch eine Menge Codierungsrichtlinien nicht gelöst worden wären. Softwaredesign ist immer noch eine Art Kunstform (zum Guten oder zum Schlechten), und ein Pool von Gehirnen ist viel besser als ein einziger.

Es ist eine ziemlich offene Frage, und die Antwort ist genauso offen:

Jede Richtlinie sollte weniger kosten als der Nutzen, den sie bringt.

Seien Sie vorsichtig, weil jede Seite der Gleichung einige versteckte Teile enthält.

Die Kosten für die Implementierung können beinhalten, dass vollkommen gute Alternativen ausgeschlossen werden, Kreativität und Innovation erstickt werden und Code-Reviews dazu ermutigt werden, kleinere Übertretungen des Stils hervorzuheben anstatt echte Probleme anzugehen.

Der Wert der Vorteile kann für einen vielbeschäftigten Entwickler in Eile nicht greifbar (und damit frustrierend) sein, kann aber dazu führen, dass die Marke Ihres Unternehmens stärker ist oder neue Mitarbeiter schneller in das Projekt einbindet - etwas, das den kleinen Zuwachs überwiegen könnte Kosten der Einhaltung.

Codierungsrichtlinien erleichtern es anderen, Ihren Code zu lesen. Selbst wenn Sie Code für sich selbst schreiben und der einzige Entwickler sind, kann es nützlich sein, eine Reihe von Richtlinien zu finden, die in der Branche allgemein akzeptiert sind und sich daran halten. Es wird es Ihnen leichter machen, den Code anderer Leute zu lesen und zu einem späteren Zeitpunkt in ein größeres Team zu passen.

Wenn Sie .net verwenden, werfen Sie einen Blick auf StyleCop. Standardmäßig enthält es Standards, die MS selbst verwenden und zum Entwerfen des .NET-Frameworks verwenden. Sie können es von hier bekommen:

Ссылка

Sie können Regeln, die Sie nicht mögen, deaktivieren und eigene hinzufügen. Es kann sogar geschrieben werden, um die Regeln zu erzwingen, wenn der Code eingecheckt wird. Das Tolle daran ist, dass wenn Sie wirklich neu in dieser Art von Sachen sind, es Ihnen genau sagen wird, was Sie falsch machen. Wenn Sie noch einen Schritt weiter gehen wollen, schauen Sie sich Resharper an. Es ist die gleiche Art von Sache, aber tut es in Echtzeit, während Sie tippen (obwohl standardmäßig ein etwas anderer Standard verwendet wird.

Ich bin sicher, es gibt ähnliche Programme in anderen Sprachen, wenn c # nicht dein Ding ist!

Ich möchte ein Coding-Standarddokument, um religiöse Argumente für das Team aufzulösen.

Für die Fragen, bei denen es mehrere lohnende Antworten gibt und die Leute dazu neigen, lange Zeit über sie zu streiten, wollen wir Konsistenz über das gesamte Projekt hinweg bekommen und vermeiden, viel Zeit damit zu verbringen, sie zu diskutieren.

Gute Beispiele sind "TABs vs. Spaces" und "K & amp; R vs ANSI Brace Placement". Nehmen Sie eine Umfrage im Team vor, treffen Sie eine Entscheidung und schreiben Sie sie auf. Wenden Sie die Entscheidung auf alle vorhandenen Codes gleichzeitig an und überprüfen Sie sie selbst. Besprechen Sie es nie wieder.

Juval Lowys C # -Codierrichtlinien sind ein hervorragendes Beispiel für eine geeignete Richtlinie . Ich habe ein paar Dinge, die ich ändern würde, aber in den meisten Fällen ist es fantastisch.

Ich mag auch die Idee eines Codierungsstils, der Entwicklern hilft, schlechten / fehlerhaften Code visuell zu identifizieren. Zum Beispiel kann es hilfreich sein, den Typ einer Variablen in ihrem Namen anzugeben, wenn jemand versehentlich einen int-Wert oder ähnliches zuweisen soll.

Coding Guidelines sind Verhaltensregeln für Ihre Teammitglieder, damit Sie ohne viel Ärger den anderen Code lesen können.

Es wird auch die "Klammer auf Newline oder in der gleichen Zeile" Diskussionen bei Ihren Code-Review-Sitzungen aus dem Weg, die eine Menge Zeit spart; -)

Achten Sie beim Schreiben von Code-Richtlinien darauf, dass sie aus einem bestimmten Grund da sind und dass sie Ihrem Team beim Schreiben von besser lesbarem Code helfen.