Gibt es eine Namenskonvention für Git-Repositorys?

328

Zum Beispiel habe ich einen RESTful-Service namens Purchase Service. Soll ich mein Repository benennen:

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. oder etwas anderes?

Was ist die Konvention? Wie wäre es in Github? Sollten öffentliche Repositories einem Standard folgen?

git github naming-conventions Adrian M.
quelle
4
Dieser Blog-Beitrag könnte von Nutzen sein Schwerkraftdept.com/blog/…
PHeiberg

Antworten:

379

Ich würde gehen für purchase-rest-service. Gründe dafür:

  1. Was ist "Kaufaufenthalt"? Lange, verkettete Wörter sind schwer zu verstehen. Ich weiß, ich bin Deutscher. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."

  2. "_" ist schwerer zu tippen als "-"

Aaron Digulla
quelle
150
Ich verstehe nicht (wirklich), aber hast du kein S in ... auschreibung ... verpasst?
Vili
6
@adimauro: Es handelt sich um eine Bewerbung um eine offene Stelle als Assistent zum Ausfüllen von Formularen für Kapitänspatente von Donaudampfbooten.
Aaron Digulla
6
Gibt es einen bestimmten Grund, warum Sie camelCase nicht bevorzugen? Dies ist meine Namenskonvention für allgemeine Elemente, da keine Sonderzeichen verwendet werden.
10gistic
31
@ 10gistic Der Repo-Name wird häufig in URLs (z. B. auf Github) angezeigt, bei denen die Groß- und Kleinschreibung nicht berücksichtigt oder sogar in Kleinbuchstaben umgewandelt werden kann. Aus diesem Grund ist camelCase eine schlechte Idee. Ich glaube nicht, dass Github dies tut, aber es scheint immer noch besser, sicher zu sein.
JDG
19
Jungs im GitHub verwenden Bindestriche. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…
airato
72

Das Problem mit Kamelfällen ist, dass es häufig unterschiedliche Interpretationen von Wörtern gibt - zum Beispiel checkinService vs checkInService. In Übereinstimmung mit Aarons Antwort ist es bei der automatischen Vervollständigung schwierig, wenn Sie viele ähnlich benannte Repos haben, ständig überprüfen zu müssen, ob die Person, die das Repo erstellt hat, das Ihnen am Herzen liegt, eine bestimmte Aufschlüsselung der Groß- und Kleinbuchstaben verwendet hat. Vermeiden Sie Großbuchstaben.

Sein Punkt über Bindestriche ist ebenfalls gut beraten.

  1. Verwenden Sie Kleinbuchstaben.
  2. Verwenden Sie Bindestriche.
  3. sei genau. Möglicherweise müssen Sie später zwischen ähnlichen Ideen unterscheiden - dh verwenden Sie den Kauf-Rest-Service anstelle des Service oder des Rest-Service.
  4. konsequent sein. Berücksichtigen Sie die Verwendung durch die verschiedenen GIT-Anbieter. Wie sollen Ihre Repositorys sortiert / gruppiert werden?
Matthew Sandoz
quelle
3
Ihre Antwort berührt zwei wichtige Punkte, die die Top-Antwort nicht berührt.
Will Beason
4
Wie kann man besser vergessen, ob es sich um einen Check-in-Service oder einen Check-in-Service handelt, als zu vergessen, ob es sich um check-in-Service oder check-in-Service handelt?
MarredCheese
Camel Case ist auch für Nicht-Muttersprachler schwieriger.
Ben Aveling
48

lowercase-with-hyphens ist der Stil, den ich am häufigsten auf GitHub sehe. *

lowercase_with_underscores ist wahrscheinlich der zweitbeliebteste Stil, den ich sehe.

Ersteres ist meine Präferenz, weil es Tastenanschläge spart.

* Anekdotisch; Ich habe keine Daten gesammelt.

Dennis
quelle
8
Bindestriche haben auch SEO-Vorteile. Dies ist möglicherweise keine wichtige Überlegung, aber da es sich um URLs handelt, ist dies relevant.
Michael Scheper
12
Bindestriche haben noch einen weiteren Vorteil: Sie sind in unterstrichenen Hyperlinks leichter zu erkennen (wobei Unterstriche leicht mit Leerzeichen verwechselt werden können).
Jeroen
1
Wie Sie bereits erwähnt haben , ist es lowercase-with-hyphens
schwierig
21

Denken Sie daran, dass ein Git-Repo in ein beliebiges Stammverzeichnis Ihrer Wahl geklont werden kann, ohne eine bestimmte Namenswahl zu bevorzugen:

git clone https://github.com/user/repo.git myDir

Hier repo.gitwürde in die geklont werdenmyDir Verzeichnis .

Selbst wenn Ihre Namenskonvention für ein öffentliches Repo etwas falsch wäre, wäre es dennoch möglich, sie auf der Clientseite zu korrigieren.

Aus diesem Grund gibt es in einer verteilten Umgebung, in der jeder Client tun kann, was er will, keine Namenskonvention für Git Repo.
(außer " xxx.git" für die bloße Form des Repos ' xxx' zu reservieren )
Möglicherweise gibt es eine Namenskonvention für den REST-Service (ähnlich wie " Gibt es Richtlinien für Namenskonventionen für REST-APIs? "), aber das ist ein separates Problem.

VonC
quelle
4
Guter Punkt. Das Festlegen des Repo-Namens auf der Client-Seite beweist jedoch, dass eine Namenskonvention hilfreich wäre. Denkst du nicht? Warum es reparieren, wenn es überhaupt einer Konvention folgte? Vielleicht hat mich Maven sehr beeinflusst.
Adrian M
1
@AdrianM Mein Punkt ist: Ja, eine Namenskonvention ist nützlich, aber sie hat nichts mit Git oder GitHub zu tun und alles mit dem, was Sie mit diesem bestimmten Repo machen wollen. Die Antwort auf Ihre Frage lautet also "Nein, es gibt keine Namenskonvention für Git-Repositorys".
VonC
8

Vielleicht wird nur mein Java- und C-Hintergrund angezeigt, aber ich bevorzuge CamelCase (CapCase) gegenüber Interpunktion im Namen. Meine Arbeitsgruppe verwendet solche Namen, wahrscheinlich um mit den Namen der App oder des Dienstes übereinzustimmen, die das Repository enthält.

SteveW
quelle
6
Dieser Beitrag ist spärlich und es ist nicht meine persönliche Präferenz, aber er erwähnt immer noch einen Vorteil, dass die Projektnamen in Java Kamelfälle sind und es ein wenig Trost in der Kongruenz gibt. Sind wir sicher, dass die Abstimmungen hier nicht nur eine Namensverzerrung sind?
Eremzeit
1
Einverstanden. In den anderen Antworten werden die Nachteile von camelCase erörtert, aber in der Java-Welt wäre es durchaus vernünftig, zu entscheiden, dass camelCase sowieso besser ist ... insbesondere für Projekte, die die Windows-Welt glücklicherweise nicht kennen.
Michael Scheper
11
Pedantische öffentliche Bekanntmachung: PascalCase ist nicht camelCase.
MarredCheese
0

Wenn Sie vorhaben , ein PHP-Paket zu erstellen, möchten Sie es höchstwahrscheinlich in Packagist einfügen , um es mit Composer für andere verfügbar zu machen. Der Komponist hat die Namenskonvention as zu verwendende vendorname/package-name-is-lowercase-with-hyphens.

Wenn Sie ein JS-Paket erstellen möchten, möchten Sie wahrscheinlich npm verwenden. Einer von ihnen Namenskonventionen besteht darin, keine Großbuchstaben in der Mitte Ihres Paketnamens zuzulassen.

Daher würde ich PHP- und JS-Paketen empfehlen, lowercase-with-hyphensIhre Pakete in Composer oder npm identisch mit Ihrem Paket auf GitHub zu verwenden und zu benennen.

Adam
quelle