Existe uma convenção de nomenclatura para repositórios git?

328

Por exemplo, eu tenho um serviço RESTful chamado Serviço de Compra. Devo nomear meu repositório:

purchaserestservice
purchase-rest-service
purchase_rest_service
ou alguma outra coisa?

Qual é a convenção? Que tal no Github? Os repositórios públicos devem seguir algum padrão?

git github naming-conventions

— Adrian M
fonte

4

Esta publicação no blog pode ser de alguma utilidade gravitydept.com/blog/…

— PHeiberg

379

Eu iria purchase-rest-service. Razões:

O que é "pur chase rests ervice"? Palavras longas e concatenadas são difíceis de entender. Eu sei, sou alemã. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung".
"_" é mais difícil de digitar do que "-"

— Aaron Digulla
fonte

151

Eu realmente não entendo, mas você não perdeu um S em ... auschreibung ...?

— Vili

6

@adimauro: É um pedido de vaga aberta como assistente para preencher formulários de patentes de capitão de barcos a vapor do Danúbio.

— Aaron Digulla

6

Algum motivo específico para você não preferir o camelCase? Essa é a minha convenção de nomenclatura de itens comuns, pois ela não usa caracteres especiais.

— 10gistic

31

@ 10gistic, o nome do repositório é frequentemente visto em URLs (por exemplo, no github) que podem fazer distinção entre maiúsculas e minúsculas ou mesmo convertidos em minúsculas, e por esse motivo, camelCase é uma má ideia. Eu não acho que o github faça isso, mas ainda parece melhor salvar.

— Jdg #

19

Os caras do GitHub usam hífens. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…

— airato

72

O problema com o caso camel é que geralmente há diferentes interpretações de palavras - por exemplo, checkinService vs checkInService. Seguindo a resposta de Aaron, é difícil com o preenchimento automático se você tiver muitos repositórios com nomes semelhantes para verificar constantemente se a pessoa que criou o repositório com o qual você se preocupa usou uma determinada discriminação das maiúsculas e minúsculas. evite maiúsculas.

Seu argumento sobre traços também é bem recomendado.

use letras minúsculas.
use traços.
seja específico. pode ser necessário diferenciar idéias semelhantes posteriormente - por exemplo, usar o serviço de compra e reposição em vez de serviço ou serviço de reposição.
ser consistente. considere o uso de vários fornecedores de GIT - como você deseja que seus repositórios sejam classificados / agrupados?

— Matthew Sandoz
fonte

3

Sua resposta aborda duas questões importantes, a resposta principal não.

— Will Beason

4

Como é esquecer se é serviço de check-in ou serviço de check-in melhor do que esquecer se é checkinService ou checkInService?

— MarredCheese 9/04/19

O estojo de camelo também é mais difícil para falantes não nativos.

— Ben Aveling

48

lowercase-with-hyphens é o estilo que eu mais vejo no GitHub. *

lowercase_with_underscores é provavelmente o segundo estilo mais popular que eu vejo.

A primeira é a minha preferência porque salva as teclas digitadas.

^{* Anedótico; Não coletei nenhum dado.}

— Dennis
fonte

8

Os hífens também têm vantagens em SEO. Isso pode não ser uma consideração importante, mas como estamos falando de URLs, é relevante.

— precisa

12

Os hífens também têm outra vantagem: são mais fáceis de localizar em hiperlinks sublinhados (onde sublinhados podem ser facilmente confundidos com espaços).

— Jeroen

1

Difícil de dados recolher o que você mencionou, mas eu fui para github.com/trending/developers e viu apenas o primeiro estilo que tem sido mencionado:lowercase-with-hyphens

— SATA

21

Sem favorecer nenhuma opção de nomenclatura específica, lembre-se de que um repositório git pode ser clonado em qualquer diretório raiz de sua escolha:

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

Aqui repo.gitseria clonado nomyDir diretório

Portanto, mesmo que sua convenção de nomenclatura para um repositório público acabe ligeiramente incorreta, ainda será possível corrigi-la no lado do cliente.

É por isso que, em um ambiente distribuído onde qualquer cliente pode fazer o que quiser, não há realmente uma convenção de nomenclatura para o repositório Git.
(exceto para reservar " xxx.git" para a forma simples do repositório ' xxx')
Pode haver uma convenção de nomenclatura para o serviço REST (semelhante a " Existem diretrizes de convenção de nomenclatura para APIs REST? "), mas esse é um problema separado.

— VonC
fonte

4

Bom ponto. No entanto, a fixação do nome do repositório no lado do cliente prova que ter uma convenção de nomenclatura seria útil. Você não acha? Por que corrigi-lo se seguiu uma convenção em primeiro lugar? Talvez o maven tenha me influenciado muito.

— Adrian M

1

@AdrianM meu argumento é: sim, uma convenção de nomenclatura é útil, mas não tem nada a ver com o Git ou o GitHub, e tudo o que você deseja fazer com esse repositório específico. Portanto, a resposta para sua pergunta é "não, não há uma convenção de nomenclatura para repositórios git".

— VonC 14/08/12

8

Talvez seja apenas meu plano de fundo Java e C, mas prefiro o CamelCase (CapCase) do que a pontuação no nome. Meu grupo de trabalho usa esses nomes, provavelmente para corresponder aos nomes do aplicativo ou serviço que o repositório contém.

— SteveW
fonte

6

Este post é escasso e não é minha preferência pessoal, mas ele ainda menciona um benefício: os nomes dos projetos em Java são camel case e há algum conforto na congruência. Temos certeza de que os votos negativos aqui não são apenas um viés de nomeação se aproximando?

— eremzeit 3/09/16

1

Acordado. As outras respostas discutem as desvantagens do camelCase, mas no mundo Java, seria perfeitamente razoável decidir que o camelCase é melhor de qualquer maneira ... especialmente para projetos que ignoram o mundo Windows.

— Michael Scheper

11

Anúncio de serviço público da Pedantic: PascalCase não é camelCase.

— MarredCheese # 9/19

0

Se você planeja criar um pacote PHP, provavelmente deseja incluir o Packagist para disponibilizá-lo para outros no compositor. O compositor tem como convenção de nomenclatura a ser usada vendorname/package-name-is-lowercase-with-hyphens.

Se você planeja criar um pacote JS, provavelmente deseja usar o npm. Uma das convenções de nomenclatura é não permitir letras maiúsculas no meio do nome do pacote.

Portanto, eu recomendaria que os pacotes PHP e JS usem lowercase-with-hyphense nomeiem seus pacotes no compositor ou npm de forma idêntica ao seu pacote no GitHub.

— Adão
fonte