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

329

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

purchaserestservice
purchase-rest-service
purchase_rest_service
или что-то другое?

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

git github naming-conventions

— Адриан М
источник

4

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

— Фейберг

379

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

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

— Аарон Дигулла
источник

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. Как и в случае с ответом Аарона, при автозаполнении трудно, если у вас есть много репо с одинаковыми именами, чтобы постоянно проверять, использовал ли человек, создавший репо, который вам нужен, определенную разбивку в верхнем и нижнем регистре. избегайте прописных букв

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

используйте строчные буквы
использовать тире.
быть конкретной. Вы можете обнаружить, что вам придется различать похожие идеи позже - то есть использовать услугу покупки-отдыха вместо обслуживания или отдыха.
быть последовательным. Рассмотрите использование различных поставщиков 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? "), но это отдельная проблема.

— VonC
источник

4

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

— Адриан М

1

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

— VonC

8

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

— SteveW
источник

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.

— Адам
источник