Чи існує угода про іменування для git сховищ?

Наприклад, у мене є RESTful сервіс під назвою "Purchase Service". Чи потрібно назвати своє сховище:

1. purchaserestservice
2. purchase-rest-service
3. purchase_rest_service
4. чи щось інше?

Що таке умовність? Як щодо Github? Чи повинні публічні сховища дотримуватися певного стандарту?

Я б пішов на purchase-rest-service. Причини:

1. Що таке "гонитви за погонами"? Довгі зв'язані слова важко зрозуміти. Я знаю, я німець. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."

2. "_" важче набрати, ніж "-"

Проблема випадку з верблюдами полягає в тому, що часто трапляються різні тлумачення слів - наприклад, checkinService vs checkInService. Ідучи разом з відповіддю Аарона, складно з автоматичним завершенням, якщо у вас є багато подібних репостів, які доведеться постійно перевіряти, чи користувач, який створив репо, про який ви дбаєте, використовував певну подію верхніх і нижніх справ. уникайте верхнього регістру.

Його думка щодо тире також добре вказується.

1. використовувати малі регістри.
2. використовувати тире.
3. бути специфічним. Ви можете виявити, що вам доведеться пізніше розрізняти подібні ідеї - тобто використовувати послугу покупка-відпочинок замість послуги або послуги відпочинку.
4. бути послідовним. розглянути можливість використання від різних постачальників GIT - як ви хочете, щоб ваші сховища були відсортовані / згруповані?

lowercase-with-hyphens це стиль, який я найчастіше бачу в GitHub. *

lowercase_with_underscores це, мабуть, другий за популярністю стиль, який я бачу.

Перший є моїм уподобанням, оскільки це економить натискання клавіш.

^{* Анекдотичний; Я не збирав жодних даних.}

Не віддаючи перевагу жодному вибору імен, пам’ятайте, що git repo може бути клонований у будь-яку кореневу директорію на ваш вибір:

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

Тут repo.gitбуло б клоновано до myDirкаталогу.

Тож навіть якщо ваш договір про іменування для публічного репо в кінцевому підсумку виявився дещо невірним, його все одно можна буде виправити на стороні клієнта.

Ось чому в розподіленому середовищі, де будь-який клієнт може робити все, що завгодно, насправді не існує конвенції про іменування для Git repo.
(за винятком резервування " xxx.git" для голої форми репо " xxx")
Можливо, буде встановлено умову іменування для REST-служби (подібно до " Чи є вказівки щодо встановлення імен для API REST API "), але це окрема проблема.

Можливо, це лише мій показ Java та C, але я віддаю перевагу CamelCase (CapCase) над розділовими знаками. Моя робоча група використовує такі імена, ймовірно, щоб відповідати іменам програми чи послуги, що містить сховище.

Якщо ви плануєте створити пакет PHP, ви, швидше за все, хочете поставити програму Packagist, щоб зробити його доступним для інших з композитором. Композитор має в якості імен-конвенції до використання vendorname/package-name-is-lowercase-with-hyphens.

Якщо ви плануєте створити пакет JS, ви, ймовірно, хочете використовувати npm. Одне з умов їх іменування - забороняти великі літери посеред імені вашого пакета.

Тому я рекомендую для пакетів PHP та JS використовувати lowercase-with-hyphensта називати ваші пакунки в композиторі чи npm ідентично вашому пакету на GitHub.