例如,我有一个名为 Purchase Service 的 RESTful 服务。我应该命名我的存储库:
purchaserestservice purchase-rest-service purchase_rest_service 还是其他?
什么是约定?在 Github 上怎么样?公共存储库应该遵循某种标准吗?
我会选择purchase-rest-service
。原因:
什么是“购买休息服务”?长而连在一起的词很难理解。我知道,我是德国人。 “Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung。” “_”比“-”更难输入
Camel case 的问题在于,通常对单词有不同的解释——例如,checkinService 与 checkInService。根据 Aaron 的回答,如果您有许多类似名称的存储库必须不断检查创建您关心的存储库的人是否使用了大写和小写的某种细分,那么自动完成是很困难的。避免大写。
他关于破折号的观点也是明智的。
使用小写。使用破折号。请明确点。稍后您可能会发现您必须区分相似的想法 - 即使用 purchase-rest-service 而不是 service 或 rest-service。始终如一。考虑各种 GIT 供应商的使用情况——您希望如何对存储库进行排序/分组?
lowercase-with-hyphens
是我在 GitHub 上最常看到的样式。*
lowercase_with_underscores
可能是我看到的第二受欢迎的样式。
前者是我的首选,因为它可以节省击键。
*轶事;我没有收集任何数据。
lowercase-with-hyphens
在不偏爱任何特定命名选择的情况下,请记住 git repo 可以克隆到您选择的任何根目录中:
git clone https://github.com/user/repo.git myDir
这里 repo.git
将被克隆到 myDir
目录中。
因此,即使您对公共 repo 的命名约定最终有点不正确,仍然可以在客户端对其进行修复。
这就是为什么在任何客户端都可以为所欲为的分布式环境中,Git 存储库没有真正的命名约定。
(除了保留“xxx.git
”对于 repo 'xxx
' 的 bare 形式)
REST 服务可能有命名约定(类似于“Are there any naming convention guidelines for REST APIs?”),但这是一个单独的问题。
也许这只是我的 Java 和 C 背景显示,但我更喜欢 CamelCase (CapCase) 而不是名称中的标点符号。我的工作组使用这样的名称,可能是为了匹配存储库包含的应用程序或服务的名称。
如果您计划创建一个 PHP 包,您很可能希望将其放入 Packagist 以使其可用于其他使用 composer。 Composer 具有使用 vendorname/package-name-is-lowercase-with-hyphens
的 as naming-convention。
如果你打算创建一个 JS 包,你可能想要使用 npm。他们的 naming conventions 之一是不允许在您的包名称中间使用大写字母。
因此,我建议 PHP 和 JS 包使用 lowercase-with-hyphens
并将您的包在 composer 或 npm 中命名为与您在 GitHub 上的包相同。