Esiste una convenzione di denominazione per i repository git?

329

Ad esempio, ho un servizio RESTful chiamato Servizio acquisti. Devo nominare il mio repository:

purchaserestservice
purchase-rest-service
purchase_rest_service
o qualcos'altro?

Qual è la convention? Che ne dici di Github? I repository pubblici dovrebbero seguire alcuni standard?

git github naming-conventions

— Adrian M
fonte

4

Questo post sul blog potrebbe essere di qualche utilità gravitydept.com/blog/…

— PHeiberg

379

Vorrei andare purchase-rest-service. Motivi:

Che cos'è "pur chase rests ervice"? Le parole lunghe e concatenate sono difficili da capire. Lo so, sono tedesco. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."
"_" è più difficile da digitare di "-"

— Aaron Digulla
fonte

151

Non capisco (davvero), ma non ti sei perso una S in ... auschreibung ...?

— Vili,

6

@adimauro: è una domanda di posizione aperta come assistente per compilare moduli per i brevetti dei capitani delle navi a vapore del Danubio.

— Aaron Digulla,

6

Qualche motivo particolare per cui non preferisci camelCase? Questa è la mia convenzione sulla denominazione di oggetti comuni, poiché non utilizza caratteri speciali.

— 10

31

@ 10gistic il nome del repository viene spesso visualizzato negli URL (ad es. Su github) che potrebbero non distinguere tra maiuscole e minuscole o persino convertiti in lettere minuscole, e per questo motivo camelCase è una cattiva idea. Non penso che Github lo faccia, ma sembra ancora meglio essere salvato.

— giovedì

19

I ragazzi di GitHub usano trattini. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…

— airato

72

Il problema con il caso dei cammelli è che spesso ci sono diverse interpretazioni delle parole, ad esempio checkinService vs checkInService. Accanto alla risposta di Aaron, è difficile con il completamento automatico se si dispone di molti repository con nomi simili che devono costantemente verificare se la persona che ha creato il repository a cui tieni ha utilizzato una certa suddivisione delle lettere maiuscole e minuscole. evitare maiuscole.

Anche il suo punto sui trattini è ben consigliato.

usa lettere minuscole.
usa trattini.
Sii specifico. potresti scoprire di dover distinguere tra idee simili in un secondo momento, ad esempio utilizzare il servizio di acquisto-riposo anziché servizio o servizio di riposo.
essere coerenti. considerare l'utilizzo da parte dei vari fornitori GIT: come si desidera che i repository vengano ordinati / raggruppati?

— Matthew Sandoz
fonte

3

La tua risposta tocca due questioni importanti, la risposta principale no.

— Will Beason il

4

In che modo dimenticare se è il servizio di check-in o il servizio di check-in è meglio che dimenticare se è checkinService o checkInService?

— MarredCheese

La custodia del cammello è anche più difficile per i non madrelingua.

— Ben Aveling il

48

lowercase-with-hyphens è lo stile che vedo più spesso su GitHub. *

lowercase_with_underscores è probabilmente il secondo stile più popolare che vedo.

Il primo è la mia preferenza perché salva i tasti.

^{* Aneddotico; Non ho raccolto alcun dato.}

— Dennis
fonte

8

I trattini hanno anche vantaggi SEO. Questa potrebbe non essere una considerazione importante, ma poiché stiamo parlando di URL, è rilevante.

— Michael Scheper,

12

I trattini hanno anche un altro vantaggio: sono più facili da individuare nei collegamenti ipertestuali sottolineati (dove i trattini bassi potrebbero essere facilmente scambiati per spazi).

— Jeroen,

1

Difficile raccogliere dati come hai menzionato, ma sono andato su github.com/trending/developers e ho visto solo lo stile precedente che è stato menzionato:lowercase-with-hyphens

— SaTa,

21

Senza favorire alcuna particolare scelta di denominazione, ricorda che un repository git può essere clonato in qualsiasi directory root di tua scelta:

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

Qui repo.gitverrebbe clonato nella myDirdirectory.

Pertanto, anche se la convenzione di denominazione per un repository pubblico fosse leggermente errata, sarebbe comunque possibile correggerla sul lato client.

Questo è il motivo per cui, in un ambiente distribuito in cui qualsiasi client può fare quello che vuole, non esiste davvero una convenzione di denominazione per il repository Git.
(tranne che per riservare " xxx.git" per la forma nuda del repository ' xxx')
Potrebbe esserci una convenzione di denominazione per il servizio REST (simile a " Esistono linee guida per la convenzione di denominazione per le API REST? "), ma questo è un problema separato.

— VonC
fonte

4

Buon punto. Tuttavia, correggere il nome del repository sul lato client dimostra in qualche modo che avere una convenzione di denominazione sarebbe utile. Non pensi? Perché risolverlo se in primo luogo ha seguito una convenzione? Forse la maven mi ha influenzato molto.

— Adrian M,

1

@AdrianM il mio punto è: sì, una convenzione di denominazione è utile, ma non ha nulla a che fare con Git o GitHub e tutto ciò che vuoi fare con quel particolare repository. Quindi la risposta alla tua domanda è "no, non esiste una convenzione di denominazione per i repository git".

— VonC

8

Forse è solo il mio background Java e C in mostra, ma preferisco CamelCase (CapCase) rispetto alla punteggiatura nel nome. Il mio gruppo di lavoro utilizza tali nomi, probabilmente per abbinare i nomi dell'app o del servizio contenuti nel repository.

— SteveW
fonte

6

Questo post è scarso e non è una mia preferenza personale, ma sta ancora citando un vantaggio, che i nomi dei progetti in Java sono casi di cammello e c'è un certo conforto in congruenza. Siamo certi che i downvotes qui non siano solo una propensione alla denominazione?

— eremzeit,

1

Concordato. Le altre risposte discutono gli svantaggi di camelCase, ma nel mondo Java, sarebbe del tutto ragionevole decidere in ogni caso che camelCase è meglio ... specialmente per i progetti beati ignoranti del mondo Windows.

— Michael Scheper,

11

Annuncio di servizio pubblico pedante: PascalCase non è camelCase.

— MarredCheese

0

Se hai intenzione di creare un pacchetto PHP, molto probabilmente vorrai metterlo su Packagist per renderlo disponibile per altri con compositore. Il compositore ha come convenzione di denominazione da usare vendorname/package-name-is-lowercase-with-hyphens.

Se si prevede di creare un pacchetto JS, probabilmente si desidera utilizzare npm. Una delle loro convenzioni di denominazione è di non consentire lettere maiuscole nel mezzo del nome del pacchetto.

Pertanto, consiglierei ai pacchetti PHP e JS di usare lowercase-with-hyphense nominare i pacchetti in compositore o npm in modo identico al pacchetto su GitHub.

— Adamo
fonte