¿Existe una convención de nomenclatura para los repositorios git?

329

Por ejemplo, tengo un servicio RESTful llamado Servicio de compra. ¿Debo nombrar mi repositorio?

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. ¿o algo mas?

¿Qué es la convención? ¿Qué tal en Github? ¿Deben los repositorios públicos seguir algún estándar?

git github naming-conventions Adrian M
fuente
44
Esta publicación de blog podría ser de alguna utilidad gravitydept.com/blog/…
PHeiberg

Respuestas:

379

Yo iría a purchase-rest-service. Razones:

  1. ¿Qué es el "servicio de compras en línea"? Las palabras largas y concatenadas son difíciles de entender. Lo sé, soy alemán. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung".

  2. "_" es más difícil de escribir que "-"

Aaron Digulla
fuente
151
No entiendo (realmente), pero ¿no te perdiste una S en ... auschreibung ...?
Vili
66
@adimauro: es una solicitud para un puesto abierto como asistente para completar formularios para patentes de capitán de barcos de vapor del Danubio.
Aaron Digulla
66
¿Alguna razón particular por la que no prefieres camelCase? Esa es mi convención de nomenclatura de elementos comunes, ya que no utiliza caracteres especiales.
10gistic
31
@ 10gistic el nombre del repositorio a menudo se ve en URL (por ejemplo, en github) que pueden ser insensibles a mayúsculas o incluso convertidas a minúsculas, y por esta razón camelCase es una mala idea. No creo que github haga esto, pero aún así parece mejor estar salvado.
Jueves
19
Los chicos de GitHub usan guiones. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…
airato
72

El problema con el caso del camello es que a menudo hay diferentes interpretaciones de las palabras, por ejemplo, checkinService vs checkInService. Siguiendo la respuesta de Aaron, es difícil con la finalización automática si tiene muchos repositorios con nombres similares para tener que verificar constantemente si la persona que creó el repositorio que le interesa utilizó un cierto desglose de las mayúsculas y minúsculas. evitar mayúsculas

Su punto sobre los guiones también está bien aconsejado.

  1. use minúsculas.
  2. usa guiones.
  3. se específico. es posible que tenga que diferenciar ideas similares más adelante, es decir, utilice el servicio de compra-descanso en lugar del servicio o el servicio de descanso.
  4. se consistente. considere el uso de varios proveedores de GIT: ¿cómo desea que se ordenen / agrupen sus repositorios?
Matthew Sandoz
fuente
3
Su respuesta toca dos cuestiones importantes que la respuesta principal no.
Will Beason
44
¿Cómo es mejor olvidar si es checkin-service o check-in-service que olvidar si es checkinService o checkInService?
MarredCheese
El caso Camel también es más difícil para los hablantes no nativos.
Ben Aveling
48

lowercase-with-hyphens es el estilo que más veo en GitHub. *

lowercase_with_underscores Es probablemente el segundo estilo más popular que veo.

El primero es mi preferencia porque ahorra pulsaciones de teclas.

* Anecdótico; No he recopilado ningún dato.

Dennis
fuente
8
Los guiones también tienen ventajas de SEO. Puede que esto no sea una consideración importante, pero como estamos hablando de URL, es relevante.
Michael Scheper
12
Los guiones también tienen otra ventaja: son más fáciles de detectar en hipervínculos subrayados (donde los guiones bajos pueden confundirse fácilmente con espacios).
Jeroen
1
Es difícil recopilar datos como ha mencionado, pero fui a github.com/trending/developers y vi solo el estilo anterior que se ha mencionado:lowercase-with-hyphens
SaTa
21

Sin favorecer ninguna opción de nomenclatura en particular, recuerde que un repositorio de git se puede clonar en cualquier directorio raíz de su elección:

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

Aquí repo.gitsería clonado en el myDirdirectorio.

Por lo tanto, incluso si su convención de nomenclatura para un repositorio público resultó ser ligeramente incorrecta, aún sería posible solucionarlo en el lado del cliente.

Es por eso que, en un entorno distribuido donde cualquier cliente puede hacer lo que quiera, no hay realmente una convención de nomenclatura para el repositorio de Git.
(excepto para reservar " xxx.git" para la forma simple del repositorio ' xxx')
Puede haber una convención de nomenclatura para el servicio REST (similar a " ¿Hay alguna pauta de convención de nomenclatura para las API REST? "), pero ese es un problema por separado.

VonC
fuente
44
Buen punto. Sin embargo, corregir el nombre del repositorio en el lado del cliente demuestra un poco que sería útil tener una convención de nomenclatura. ¿No te parece? ¿Por qué arreglarlo si siguió una convención en primer lugar? Quizás Maven me ha influenciado mucho.
Adrian M
1
@AdrianM mi punto es: sí, una convención de nomenclatura es útil, pero no tiene nada que ver con Git o GitHub, y todo con lo que quieres hacer con ese repositorio en particular. Entonces la respuesta a su pregunta es "no, no existe una convención de nomenclatura para los repositorios git".
VonC
8

Tal vez solo se muestre mi fondo Java y C, pero prefiero CamelCase (CapCase) sobre la puntuación en el nombre. Mi grupo de trabajo usa dichos nombres, probablemente para que coincidan con los nombres de la aplicación o el servicio que contiene el repositorio.

SteveW
fuente
66
Esta publicación es escasa y no es mi preferencia personal, pero aún menciona un beneficio, que los nombres de los proyectos en Java son casos de camellos y hay cierta comodidad en la congruencia. ¿Estamos seguros de que los votos negativos aquí no son solo un sesgo de nombres que se arrastra?
eremzeit
1
Convenido. Las otras respuestas discuten las desventajas de camelCase, pero en el mundo de Java, sería completamente razonable decidir que camelCase es mejor de todos modos ... especialmente para proyectos felizmente ignorantes del mundo de Windows.
Michael Scheper el
11
Anuncio de servicio público pedagógico: PascalCase no es camelCase.
MarredCheese
0

Si planea crear un paquete PHP, lo más probable es que quiera ponerlo en Packagist para que esté disponible para otros con el compositor. Composer tiene la convención de nomenclatura para usar vendorname/package-name-is-lowercase-with-hyphens.

Si planea crear un paquete JS, probablemente quiera usar npm. Una de sus convenciones de nomenclatura es no permitir letras mayúsculas en el medio del nombre de su paquete.

Por lo tanto, recomendaría que los paquetes PHP y JS usen lowercase-with-hyphensy nombren sus paquetes en composer o npm de forma idéntica a su paquete en GitHub.

Adán
fuente