HINWEIS: Diese Website wurde eingestellt. Die Website wird nach dem 31. Januar 2023 eingestellt. Der Traffic wird auf die neue Website unter https://Protop.dev weitergeleitet. In der Zwischenzeit werden nur Änderungen an aufgeführt.

Gestaltungsrichtlinien

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Dieses Dokument enthält einen Styleguide für .proto-Dateien. Wenn Sie diese Konventionen befolgen, sorgen Sie dafür, dass die Definitionen der Protokollpuffernachrichten und die entsprechenden Klassen einheitlich und leicht lesbar sind.

Da sich der Protokollpufferstil im Laufe der Zeit weiterentwickelt hat, werden Sie wahrscheinlich .proto-Dateien sehen, die in verschiedenen Konventionen oder Stilen geschrieben sind. Bitte berücksichtigen Sie den vorhandenen Stil, wenn Sie diese Dateien bearbeiten. Konsistenz ist entscheidend. Es empfiehlt sich jedoch, den derzeit besten Stil zu verwenden, wenn Sie eine neue .proto-Datei erstellen.

Standarddateiformatierung

  • Die Zeilenlänge darf 80 Zeichen nicht überschreiten.
  • Einzug von 2 Leerzeichen verwenden
  • Bevorzugen Sie die Verwendung von doppelten Anführungszeichen für Strings.

Dateistruktur

Dateien sollten den Namen lower_snake_case.proto haben

Alle Dateien sollten folgendermaßen angeordnet sein:

  1. Lizenzheader (falls zutreffend)
  2. Dateiübersicht
  3. Syntax
  4. Paket
  5. Importe (sortiert)
  6. Dateioptionen
  7. Alles andere

Pakete

Paketnamen sollten in Kleinbuchstaben angegeben werden. Paketnamen sollten auf der Grundlage des Projektnamens und möglicherweise auch basierend auf dem Pfad der Datei mit den Protokollpuffertypdefinitionen eindeutig sein.

Nachrichten- und Feldnamen

Verwenden Sie „CamelCase“ (mit einem Anfangsbuchstaben) für Nachrichtennamen, z. B. SongServerRequest. Verwenden Sie für Feldnamen „Unterstriche_getrennte_Namen“ (einschließlich Feld- und Erweiterungsnamen), z. B. song_name.

message SongServerRequest {
  optional string song_name = 1;
}

Wenn Sie diese Namenskonvention für Feldnamen verwenden, erhalten Sie Zugriffsfunktionen wie die folgenden:

C++:
  const string& song_name() { ... }
  void set_song_name(const string& x) { ... }

Java:
  public String getSongName() { ... }
  public Builder setSongName(String v) { ... }

Wenn Ihr Feldname eine Zahl enthält, sollte diese nach dem Buchstaben erscheinen, nicht nach dem Unterstrich. Verwenden Sie beispielsweise song_name1 statt song_name_1.

Wiederkehrende Felder

Für wiederkehrende Felder Pluralnamen verwenden

  repeated string keys = 1;
  ...
  repeated MyMessage accounts = 17;

Enums

Verwenden Sie CamelCase (mit einem Anfangsbuchstaben) für Enum-Typnamen und CAPITALS_WITH_underSCORES für Wertnamen:

enum FooBar {
  FOO_BAR_UNSPECIFIED = 0;
  FOO_BAR_FIRST_VALUE = 1;
  FOO_BAR_SECOND_VALUE = 2;
}

Jeder Enum-Wert sollte mit einem Semikolon enden, nicht mit einem Komma. Bevorzugen Sie Enum-Werte, anstatt sie in einer sie umgebenden Nachricht zu umgeben. Der Wert null Enum sollte das Suffix UNSPECIFIED haben, da ein Server oder eine Anwendung, die einen unerwarteten Enum-Wert erhält, das Feld in der. Die Zugriffsfunktion für das Feld gibt dann den Standardwert zurück, der für Enum-Felder der erste Enum-Wert ist.

Dienste

Wenn .proto einen RPC-Dienst definiert, sollten Sie CamelCase (mit einem Anfangsbuchstaben) sowohl für den Dienstnamen als auch für alle RPC-Methodennamen verwenden:

service FooService {
  rpc GetSomething(GetSomethingRequest) returns (GetSomethingResponse);
  rpc ListSomething(ListSomethingRequest) returns (ListSomethingResponse);
}

Was du vermeiden solltest

  • Pflichtfelder (nur für proto2)
  • Gruppen (nur für proto2)