Существует ли соглашение об именах для git-репозиториев?


329

Например, у меня есть служба RESTful, которая называется «Служба покупки». Должен ли я назвать свой репозиторий:

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. или что-то другое?

Что такое конвенция? Как насчет Github? Должны ли публичные репозитории следовать каким-то стандартам?


4
Этот пост в блоге может быть полезен gravitydept.com/blog/…
Фейберг

Ответы:


379

Я бы пошел на purchase-rest-service. Причины:

  1. Что такое "погоня за ошибками"? Длинные объединенные слова трудно понять. Я знаю, я немец. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung."

  2. «_» труднее набрать, чем «-»


151
Я (на самом деле) не понимаю, но вы не пропустили S в ... auschreibung ...?
Вили

6
@adimauro: Это заявка на вакансию в качестве помощника для заполнения форм на капитанские патенты на дунайские пароходы.
Аарон Дигулла

6
По какой-то конкретной причине вы не предпочитаете camelCase? Это мое соглашение о присвоении имен обычным элементам, так как в нем не используются специальные символы.
10gistic

31
@ 10gistic имя репо часто встречается в URL (например, на github), которые могут быть нечувствительными к регистру или даже преобразованы в нижний регистр, и по этой причине camelCase - плохая идея. Я не думаю, что GitHub это делает, но все же лучше сохранить.
JDG

19
Парни в GitHub используют дефисы. habrastorage.org/getpro/habr/post_images/d34/331/a8d/…
airato

72

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

Его точка зрения о тире также хорошо рекомендуется.

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

3
Ваш ответ затрагивает два важных вопроса, которых нет в топ-ответе.
Уилл Бейсон

4
Как лучше забыть, является ли это checkin-service или check-in-service лучше, чем забыть, это checkinService или checkInService?
MarredCheese

Верблюжий кейс также сложнее для не носителей языка.
Бен Авелинг

48

lowercase-with-hyphens это стиль, который я чаще всего вижу на GitHub. *

lowercase_with_underscores вероятно, второй по популярности стиль, который я вижу.

Первый мой выбор, потому что он экономит нажатия клавиш.

* Анекдотический; Я не собрал никаких данных.


8
У дефисов также есть преимущества SEO. Это не может быть основным соображением, но поскольку мы вроде говорим об URL, это актуально.
Майкл Шепер

12
У дефисов есть и другое преимущество: их легче заметить в подчеркнутых гиперссылках (где подчеркивания могут быть легко приняты за пробелы).
Jeroen

1
Трудно собрать данные, как вы упомянули, но я зашел на github.com/trending/developers и увидел только прежний стиль, который был упомянут:lowercase-with-hyphens
SaTa

21

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

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

Вот repo.gitбы клонировать в myDirкаталог.

Таким образом, даже если ваше соглашение об именах для публичного репо окажется слегка неправильным, все равно можно будет исправить его на стороне клиента.

Вот почему в распределенной среде, где любой клиент может делать все, что он / она хочет, в действительности нет соглашения об именовании для Git-репо.
(за исключением того, чтобы зарезервировать " xxx.git" для простой формы репозитория " xxx).
Возможно, существует соглашение об именовании для службы REST (аналогично" Существуют ли какие-либо рекомендации по соглашениям об именах для API REST? "), но это отдельная проблема.


4
Хорошая точка зрения. Однако исправление имени репо на стороне клиента несколько доказывает, что было бы полезно иметь соглашение об именах. Ты не думаешь? Зачем это исправлять, если в первую очередь следовало соглашению? Может быть, Maven сильно повлиял на меня.
Адриан М

1
@AdrianM моя точка зрения такова: да, соглашение об именах полезно, но оно не имеет ничего общего с Git или GitHub, а также с тем, что вы хотите сделать с этим конкретным репо. Таким образом, ответ на ваш вопрос «нет, для git-репозиториев нет соглашения об именах».
VonC

8

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


6
Эта статья редкая, и это не мое личное предпочтение, но он по-прежнему упоминает о преимуществе, заключающемся в том, что имена проектов на Java являются верблюжьими, и в конгруэнтности есть некоторый комфорт. Уверены ли мы, что отрицательные голоса здесь - это не просто смещение имен?
eremzeit

1
Согласовано. В других ответах обсуждаются недостатки camelCase, но в мире Java было бы вполне разумным решить, что camelCase лучше, во всяком случае ... особенно для проектов, блаженно не знакомых с миром Windows.
Майкл Шепер,

11
Педантичное объявление государственной службы: PascalCase - это не CamelCase.
MarredCheese

0

Если вы планируете создать пакет PHP, вы, скорее всего, захотите добавить его в Packagist, чтобы сделать его доступным для других с помощью composer. Композитор имеет в качестве имен-конвенции к использованию vendorname/package-name-is-lowercase-with-hyphens.

Если вы планируете создать пакет JS, вы, вероятно, захотите использовать npm. Одно из соглашений об именах - не допускать прописных букв в середине имени вашего пакета.

Поэтому я бы рекомендовал пакетам PHP и JS использовать lowercase-with-hyphensи называть ваши пакеты в composer или npm идентично вашему пакету на GitHub.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.