Google Style Guide in C ++. Teil 1

Teil 1. Einführung
...
Teil 8. Benennung
Teil 9. Kommentare
...


Beim Schreiben von Code wenden wir alle die Regeln des Code-Designs an. Manchmal werden ihre eigenen Regeln erfunden, in anderen Fällen werden fertige Styleguides verwendet. Obwohl alle C ++ - Programmierer einfacher in Englisch als in ihrer Muttersprache lesen, ist es angenehmer, ein Handbuch in letzterer zu haben.
Dieser Artikel ist eine Übersetzung eines Teils des Google Style Guides in C ++ ins Russische.
Originalartikel (Gabel auf Github), aktualisierte Übersetzung .
Dies ist der einleitende Teil des Leitfadens, der die allgemeinen Fragen des „Warum?“ Behandelt.
Nach der Übersetzung gibt es auch mehrere Antworten auf mögliche Fragen.

Eintrag

C ++ ist eine der wichtigsten Programmiersprachen, die in Open-Source-Google-Projekten verwendet werden. Es ist bekannt, dass C ++ eine sehr mächtige Sprache ist. Es ist jedoch eine komplexe Sprache und kann bei falscher Verwendung eine Brutstätte von Fehlern sein, was das Lesen und Verwalten von Code erschwert.

Ziel dieses Handbuchs ist es, die Codekomplexität zu verwalten, indem detailliert beschrieben wird, wie sich das Schreiben von C ++ - Code lohnt (oder nicht lohnt). Die Regeln dieses Handbuchs vereinfachen die Codeverwaltung und erhöhen die Leistung von Codierern.

Stil - Konventionen gefolgt von C ++ - Code Der Stil ist mehr als das Formatieren einer Datei mit Code.

Die meisten von Google entwickelten Open-Source-Projekte folgen diesem Leitfaden.

Hinweis: Bei diesem Handbuch handelt es sich nicht um ein C ++ - Lernprogramm. Es wird davon ausgegangen, dass Sie mit der Sprache vertraut sind.

Ziele des Styleguides

Warum wird dieses Dokument benötigt?

Es gibt mehrere Hauptziele dieses Dokuments: das interne Warum , das einzelnen Regeln zugrunde liegt. Mit diesen Zielen können Sie lange Diskussionen vermeiden: Warum sind die Regeln und warum sollten sie befolgt werden? Wenn Sie die Ziele jeder Regel verstehen, fällt es Ihnen leichter, diesen zuzustimmen oder sie abzulehnen und Alternativen zu bewerten, wenn Sie die Regeln für sich selbst ändern.

Die Managementziele lauten wie folgt:

• Regeln müssen die Änderung wert sein.
  
  
  • Die Vorteile der Verwendung eines einzelnen Stils sollten die Unzufriedenheit der Ingenieure beim Erinnern und Verwenden der Regeln überwiegen.
  • Der Vorteil wird im Vergleich zur Codebasis ohne Anwendung von Regeln bewertet. Wenn Ihre Mitarbeiter die Regeln also immer noch nicht anwenden, ist der Vorteil sehr gering.
  • Dieses Prinzip erklärt, warum einige Regeln fehlen: Zum Beispiel verstößt goto gegen viele Prinzipien, wird aber praktisch nicht verwendet, weshalb der Leitfaden es nicht beschreibt.
• Optimiert zum Lesen, nicht zum Schreiben
  
  
  • Unsere Codebasis (und die meisten einzelnen Komponenten davon) werden für eine lange Zeit verwendet. Daher wird deutlich mehr Zeit für das Lesen dieses Codes aufgewendet als für das Schreiben.
  • Es ist uns ein klares Anliegen, dass unsere Ingenieure ein Lego haben, um Code zu lesen, zu warten und zu debuggen. Das Verlassen des Debugging- / Logging-Codes ist eine der Konsequenzen: Wenn ein Teil des Codes „seltsam“ funktioniert (zum Beispiel beim Übertragen des Besitzes eines Zeigers), kann das Vorhandensein von Texthinweisen sehr nützlich sein ( std :: unique_ptr zeigt deutlich die Übertragung des Besitzes).
• Schreiben Sie einen Code, der einem vorhandenen ähnlich ist
  
  Durch die Verwendung eines einzelnen Stils auf Codebasis können Sie zu anderen, wichtigeren Themen wechseln.
  
  Auch ein einzelner Stil fördert die Automatisierung. Und natürlich funktioniert das automatische Code-Format (oder die Ausrichtung von #include ) ordnungsgemäß, wenn es die Anforderungen des Dienstprogramms erfüllt. In anderen Fällen wird nur eine (die am besten geeignete) Regel aus dem Regelwerk verwendet, und einige Flexibilität bei der Verwendung der Regeln ermöglicht es den Leuten, weniger zu argumentieren.
• Schreiben Sie ähnlichen Code wie in der C ++ - Community (falls möglich).
  
  Die Konsistenz unseres Codes mit dem C ++ - Code anderer Organisationen und Communities ist sehr nützlich. Wenn die Funktionen von Standard-C ++ oder die akzeptierten Redewendungen der Sprache das Schreiben von Programmen erleichtern, ist dies eine Gelegenheit, sie zu verwenden. Manchmal sind der Standard und die Redewendungen jedoch für die Aufgabe schlecht geeignet. In diesen Fällen (wie unten beschrieben) ist es sinnvoll, die Verwendung einiger Standardfunktionen einzuschränken oder zu untersagen. In einigen Fällen wird Ihre Lösung erstellt, aber manchmal werden externe Bibliotheken verwendet (anstelle der Standard-C ++ - Bibliothek), und es ist zu teuer, sie auf Ihren eigenen Standard umzuschreiben.
• Vermeiden Sie unerwartete oder gefährliche Strukturen.
  
  C ++ hat nicht offensichtliche und sogar gefährliche Ansätze. Einige Codierungsstile schränken deren Verwendung ein Ihre Verwendung birgt große Risiken für die Richtigkeit des Codes.
• Vermeiden Sie Konstruktionen, die der durchschnittliche C ++ - Programmierer für abstrus und schwer zu unterstützen hält
  
  In C ++ gibt es Funktionen, die aufgrund der Komplexität des Codes im Allgemeinen nicht erwünscht sind.
  In häufig verwendetem Code ist die Verwendung von kniffligen Konstruktionen jedoch aufgrund der wiederholten Verwendung gerechtfertigter, und neue Teile des Codes werden klarer.
  
  Wenden Sie sich im Zweifelsfall an den Projektleiter.
  
  Dies ist sehr wichtig für unsere Codebasis, wie Codebesitzer und ein Support-Team ändern sich im Laufe der Zeit: Auch wenn jetzt jeder den Code versteht, können sich die Dinge in ein paar Jahren ändern.
• Betrachten Sie den Maßstab des Codes
  
  Mit einer Codebasis von über 100 Millionen Zeilen und Tausenden von Ingenieuren können Fehler und Vereinfachungen kostspielig sein. Beispielsweise ist es wichtig, das Verunreinigen des globalen Namespaces zu vermeiden: Namenskollisionen sind in einer großen Codebasis nur sehr schwer zu vermeiden, wenn alles im globalen Namespace deklariert ist.
• Optimieren Sie nach Bedarf
  
  Leistungsoptimierung ist manchmal wichtiger als das Befolgen der Codierungsregeln.

Mit diesem Dokument sollen die verständlichsten Anleitungen mit angemessenen Einschränkungen bereitgestellt werden. Wie immer hat niemand den gesunden Menschenverstand abgesagt. Mit dieser Spezifikation möchten wir Konventionen für die gesamte Google-Community in C ++ festlegen, nicht nur für einzelne Teams oder Personen. Seien Sie skeptisch gegenüber listigen oder ungewöhnlichen Designs: Die fehlende Beschränkung hat nicht immer eine Lösung. Und wenn Sie sich nicht selbst entscheiden können, fragen Sie den Chef.

C ++ Version

Jetzt sollte der Code C ++ 17 entsprechen, d.h. C ++ 2x Features sind unerwünscht. In Zukunft wird das Handbuch für neuere Versionen von C ++ angepasst.

Verwenden Sie keine benutzerdefinierten Erweiterungen .

Berücksichtigen Sie die Kompatibilität mit anderen Umgebungen, wenn Sie C ++ 14 und C ++ 17 in Ihrem Projekt verwenden möchten.

Hinweis: Links können zu Teilen des Handbuchs führen, die noch nicht übersetzt wurden.

Einige Antworten / Kommentare:

- Warum überweisen?

Ich persönlich fühle mich mit der russischen Führung wohler. Es ist auch besser, Änderungen im Styleguide mit dem russischen Text zu besprechen.

- Warum Google? Gibt es mehr (oder weniger) beliebte ...?

Das Unternehmen ist sehr bekannt, die Führung ist nicht sehr groß (es kann mühelos von einer Person übersetzt werden), es erfüllt die erforderlichen Funktionen - dieser Leitfaden ist stilvoll

- Aber das Google-Handbuch erklärt die Verwendung von veralteten (...), die Ablehnung von solchen nützlichen (...)! Warum?

Soweit ich weiß, handelt es sich bei diesem Dokument um einen Vorschlag. Sie werden etwas verwenden, etwas ändern - das ist zulässig. Führung ist eine gute Grundlage.