Czy istnieje konwencja nazewnictwa dla repozytoriów git?

328

Na przykład mam usługę RESTful o nazwie Usługa zakupu. Czy powinienem nazwać swoje repozytorium:

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. albo coś innego?

Jaka jest konwencja? Co powiesz na Github? Czy publiczne repozytoria powinny być zgodne ze standardami?

git github naming-conventions Adrian M.
źródło
4
Ten post na blogu może być przydatny gravitydept.com/blog/…
PHeiberg

Odpowiedzi:

379

Wybrałbym purchase-rest-service. Powody:

  1. Czym jest „pur chase rests ervice”? Długie, połączone słowa są trudne do zrozumienia. Wiem, jestem Niemcem. „Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung.”

  2. Trudniej jest wpisać „_” niż „-”

Aaron Digulla
źródło
151
Naprawdę nie rozumiem, ale czy nie przegapiłeś litery S w ... auschreibung ...?
Vili
6
@adimauro: Jest to aplikacja na otwartą pozycję jako asystent do wypełniania formularzy do patentów kapitańskich na parowce Dunaju.
Aaron Digulla,
6
Czy jest jakiś konkretny powód, dla którego nie preferujesz camelCase? To moja konwencja nazewnictwa pospolitych przedmiotów, ponieważ nie używa ona znaków specjalnych.
10gistic
31
@ 10gistic nazwa repo jest często widoczna w adresach URL (np. Na github), które mogą nie uwzględniać wielkości liter lub nawet konwertowane na małe litery, i dlatego camelCase to zły pomysł. Nie sądzę, że github to robi, ale wydaje się, że lepiej jest oszczędzać.
jdg
19
Faceci w GitHub używają łączników. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…
airato
72

Problem z przypadkiem wielbłąda polega na tym, że często występują różne interpretacje słów - na przykład checkinService vs checkInService. Postępując zgodnie z odpowiedzią Aarona, przy autouzupełnianiu trudno jest, jeśli masz wiele repozytoriów o podobnych nazwach, aby stale sprawdzać, czy osoba, która utworzyła repozytorium, na którym ci zależy, zastosowała pewien rozkład wielkich i małych liter. unikaj wielkich liter.

Jego punkt widzenia na myślniki jest również dobrze wskazany.

  1. używaj małych liter.
  2. użyj myślników.
  3. być specyficznym. może się okazać, że będziesz musiał później rozróżnić podobne pomysły - tj. skorzystaj z usługi kupno-odpoczynek zamiast usługi lub usługi odpoczynku.
  4. być konsekwentnym. rozważ użycie różnych dostawców GIT - jak chcesz sortować / grupować swoje repozytoria?
Matthew Sandoz
źródło
3
Twoja odpowiedź dotyczy dwóch ważnych kwestii, na które nie ma najlepszej odpowiedzi.
Will Beason
4
Jak lepiej zapomnieć, czy jest to usługa checkin-service czy check-in-service, niż zapomnieć, czy jest to checkinService, czy checkInService?
MarredCheese,
Obudowa wielbłąda jest również trudniejsza dla osób, które nie są rodzimymi użytkownikami języka.
Ben Aveling,
48

lowercase-with-hyphens to styl, który najczęściej widzę w GitHub. *

lowercase_with_underscores jest prawdopodobnie drugim najpopularniejszym stylem, jaki widzę.

To pierwsze jest moim wyborem, ponieważ oszczędza naciśnięcia klawiszy.

* Anegdota; Nie zebrałem żadnych danych.

Dennis
źródło
8
Łączniki mają również zalety SEO. To może nie być poważny problem, ale ponieważ rozmawiamy o adresach URL, jest to istotne.
Michael Scheper
12
Łączniki mają również inną zaletę: łatwiej je dostrzec w podkreślonych hiperłączach (gdzie podkreślenia można łatwo pomylić ze spacjami).
Jeroen
1
Trudno zebrać dane, jak wspomniałeś, ale poszedłem na github.com/trending/developers i zobaczyłem tylko poprzedni styl, o którym wspomniano:lowercase-with-hyphens
SaTa
21

Nie faworyzując żadnego konkretnego wyboru nazewnictwa, pamiętaj, że repozytorium git można klonować w dowolnym wybranym katalogu głównym:

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

Tutaj repo.gitzostanie sklonowany do myDirkatalogu.

Więc nawet jeśli twoja konwencja nazewnictwa dla publicznego repozytorium okazała się być nieco niepoprawna, nadal można by to naprawić po stronie klienta.

Dlatego w rozproszonym środowisku, w którym każdy klient może robić, co chce, tak naprawdę nie ma konwencji nazewnictwa dla repozytorium Git.
(z wyjątkiem rezerwy „ xxx.git” do gołej formie repo ' xxx„)
Nie może być nazewnictwo dla usługi REST (podobny do« Czy istnieją jakieś wytyczne konwencji nazewnictwa dla REST API? »), ale to osobna kwestia.

VonC
źródło
4
Słuszna uwaga. Jednak ustalenie nazwy repo po stronie klienta nieco dowodzi, że pomocna byłaby konwencja nazewnictwa. Nie sądzisz? Po co to naprawiać, jeśli przede wszystkim postępuje zgodnie z konwencją? Może maven wywarło na mnie duży wpływ.
Adrian M
1
@AdrianM mam na myśli: tak, konwencja nazewnictwa jest przydatna, ale nie ma nic wspólnego z Git lub GitHub i wszystko, co chcesz zrobić z tym konkretnym repozytorium. Odpowiedź na twoje pytanie brzmi: „nie, nie ma konwencji nazewnictwa dla repozytoriów git”.
VonC
8

Może to tylko moje tło Java i C, ale wolę CamelCase (CapCase) niż interpunkcję w nazwie. Moja grupa robocza używa takich nazw, prawdopodobnie w celu dopasowania nazw aplikacji lub usługi, które zawiera repozytorium.

SteveW
źródło
6
Ten post jest rzadki i nie jest to moje osobiste preferencje, ale wciąż wspomina o korzyściach, że nazwy projektów w Javie są wielbłądami i istnieje pewna wygoda w zgodności. Czy jesteśmy pewni, że opinie tutaj nie są po prostu wkradaniem się w nazewnictwo?
eremzeit
1
Zgoda. Inne odpowiedzi omawiają wady camelCase, ale w świecie Java byłoby całkowicie rozsądne zdecydować, że camelCase i tak jest lepszy ... szczególnie w przypadku projektów błogo ignorujących świat Windows.
Michael Scheper
11
Ogłoszenie publicznej usługi pedantycznej: PascalCase nie jest camelCase.
MarredCheese
0

Jeśli planujesz stworzyć pakiet PHP, najprawdopodobniej chcesz umieścić na Packagist, aby udostępnić go innym osobom z kompozytorem. Kompozytor ma jak nazywanie konwencję do użytku vendorname/package-name-is-lowercase-with-hyphens.

Jeśli planujesz utworzyć pakiet JS, prawdopodobnie chcesz użyć npm. Jedną z konwencji nazewnictwa jest niedopuszczanie wielkich liter na środku nazwy pakietu.

Dlatego polecam, aby pakiety PHP i JS używały lowercase-with-hyphensi nazywały twoje pakiety w kompozytorze lub npm identycznie jak twój pakiet na GitHub.

Adam
źródło