Existe-t-il une convention de dénomination pour les référentiels git?

329

Par exemple, j'ai un service RESTful appelé Service d'achat. Dois-je nommer mon référentiel:

purchaserestservice
purchase-rest-service
purchase_rest_service
ou autre chose?

Quelle est la convention? Et à Github? Les référentiels publics devraient-ils suivre une norme?

git github naming-conventions

— Adrian M
source

4

Ce billet de blog pourrait être d'une certaine utilité gravitydept.com/blog/…

— PHeiberg

379

J'irais pour purchase-rest-service. Les raisons:

Qu'est-ce que le «pur chase rests ervice»? Les mots longs et concaténés sont difficiles à comprendre. Je sais, je suis allemand. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."
"_" est plus difficile à taper que "-"

— Aaron Digulla
source

151

Je ne comprends pas (vraiment), mais vous n'avez pas manqué un S dans ... auschreibung ...?

— Vili

6

@adimauro: C'est une application comme pour un poste ouvert en tant qu'assistant pour remplir des formulaires pour les brevets de capitaine de bateaux à vapeur du Danube.

— Aaron Digulla

6

Une raison particulière pour laquelle vous ne préférez pas camelCase? C'est ma convention de dénomination des éléments communs car elle n'utilise aucun caractère spécial.

— 10

31

@ 10gistic le nom du dépôt est souvent vu dans les URL (par exemple sur github) qui peuvent être insensibles à la casse ou même converties en minuscules, et pour cette raison, camelCase est une mauvaise idée. Je ne pense pas que github le fasse, mais il semble toujours préférable d'être sauvegardé.

— jdg

19

Les gars du GitHub utilisent des tirets. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…

— airato

72

Le problème avec le cas de chameau est qu'il existe souvent des interprétations différentes des mots - par exemple, checkinService vs checkInService. En accord avec la réponse d'Aaron, la saisie semi-automatique est difficile si vous avez de nombreux référentiels de même nom pour vérifier constamment si la personne qui a créé le référentiel que vous aimez utilise une certaine ventilation des majuscules et des minuscules. éviter les majuscules.

Son point sur les tirets est également judicieux.

utilisez des minuscules.
utilisez des tirets.
être spécifique. il se peut que vous deviez faire la différence entre des idées similaires plus tard - c'est-à-dire utiliser le service d'achat-repos au lieu du service ou du service de repos.
être cohérent. envisager l'utilisation des différents fournisseurs GIT - comment voulez-vous que vos référentiels soient triés / regroupés?

— Matthew Sandoz
source

3

Votre réponse touche à deux questions importantes que la première réponse ne fait pas.

— Will Beason

4

Comment oublier s'il s'agit d'un service d'enregistrement ou d'un service d'enregistrement plutôt que d'oublier s'il s'agit de checkinService ou checkInService?

— MarredCheese

L'étui camel est également plus difficile pour les locuteurs non natifs.

— Ben Aveling

48

lowercase-with-hyphens est le style que je vois le plus souvent sur GitHub. *

lowercase_with_underscores est probablement le deuxième style le plus populaire que je vois.

Le premier est ma préférence car il enregistre les frappes.

^{* Anecdotique; Je n'ai collecté aucune donnée.}

— Dennis
source

8

Les tirets ont également des avantages SEO. Ce n'est peut-être pas une considération majeure, mais comme nous parlons un peu d'URL, c'est pertinent.

— Michael Scheper

12

Les tirets ont également un autre avantage: ils sont plus faciles à repérer dans les hyperliens soulignés (où les traits de soulignement peuvent être facilement confondus avec des espaces).

— Jeroen

1

Difficile de collecter des données comme vous l'avez mentionné, mais je suis allé sur github.com/trending/developers et je n'ai vu que l'ancien style qui a été mentionné:lowercase-with-hyphens

— SaTa

21

Sans privilégier un choix de nommage particulier, n'oubliez pas qu'un dépôt git peut être cloné dans n'importe quel répertoire racine de votre choix:

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

Ici repo.gitserait cloné dans le myDirrépertoire.

Ainsi, même si votre convention de dénomination pour un dépôt public se révélait légèrement incorrecte, il serait toujours possible de la corriger côté client.

C'est pourquoi, dans un environnement distribué où tout client peut faire ce qu'il veut, il n'y a pas vraiment de convention de dénomination pour le dépôt Git.
(sauf pour réserver " xxx.git" à la forme nue du référentiel ' xxx')
Il peut y avoir une convention de dénomination pour le service REST (similaire à " Existe-t-il des directives de convention de dénomination pour les API REST? "), mais il s'agit d'un problème distinct.

— VonC
source

4

Bon point. Cependant, la fixation du nom du référentiel côté client prouve quelque peu qu'il serait utile d'avoir une convention de dénomination. Tu ne crois pas? Pourquoi le réparer s'il suivait une convention en premier lieu? Peut-être que Maven m'a beaucoup influencé.

— Adrian M

1

@AdrianM mon point est: oui, une convention de dénomination est utile, mais elle n'a rien à voir avec Git ou GitHub, et tout avec ce que vous voulez faire avec ce référentiel particulier. La réponse à votre question est donc "non, il n'y a pas de convention de dénomination pour les référentiels git".

— VonC

8

Peut-être que c'est juste mon arrière-plan Java et C qui s'affiche, mais je préfère CamelCase (CapCase) à la ponctuation dans le nom. Mon groupe de travail utilise de tels noms, probablement pour correspondre aux noms de l'application ou du service que contient le référentiel.

— SteveW
source

6

Ce message est rare et ce n'est pas ma préférence personnelle, mais il mentionne toujours un avantage, que les noms de projet en Java sont des cas de chameau et qu'il y a un certain confort dans la congruence. Sommes-nous certains que les votes négatifs ne sont pas seulement un biais de dénomination qui s'introduit?

— eremzeit

1

D'accord. Les autres réponses discutent des inconvénients de camelCase, mais dans le monde Java, il serait tout à fait raisonnable de décider que camelCase est meilleur de toute façon ... en particulier pour les projets qui ignorent béatement le monde Windows.

— Michael Scheper

11

Annonce de service public pédant: PascalCase n'est pas camelCase.

— MarredCheese

0

Si vous envisagez de créer un package PHP, vous voudrez probablement mettre Packagist pour le rendre disponible pour d'autres avec composer. Composer a la convention de nommage as à utiliser vendorname/package-name-is-lowercase-with-hyphens.

Si vous prévoyez de créer un package JS, vous voudrez probablement utiliser npm. L'une de leurs conventions de dénomination consiste à ne pas autoriser les majuscules au milieu du nom de votre package.

Par conséquent, je recommanderais aux packages PHP et JS d'utiliser lowercase-with-hyphenset de nommer vos packages dans composer ou npm de manière identique à votre package sur GitHub.

— Adam
source