ChatGPT解决这个技术问题 Extra ChatGPT

git 存储库有命名约定吗?

例如,我有一个名为 Purchase Service 的 RESTful 服务。我应该命名我的存储库:

purchaserestservice purchase-rest-service purchase_rest_service 还是其他?

什么是约定?在 Github 上怎么样?公共存储库应该遵循某种标准吗?

这篇博文可能有用gravitydept.com/blog/…

A
Aaron Digulla

我会选择purchase-rest-service。原因:

什么是“购买休息服务”?长而连在一起的词很难理解。我知道,我是德国人。 “Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung。” “_”比“-”更难输入


我不(真的)明白,但你没有错过...auschreibung ...中的S吗?
@adimauro:这是作为助理填写多瑙河汽船船长专利表格的空缺职位的申请。
你不喜欢camelCase有什么特别的原因吗?这是我常用的通用项目命名约定,因为它不使用特殊字符。
@10gistic repo 名称经常出现在可能不区分大小写甚至转换为小写的 URL(例如在 github 上)中,因此 camelCase 是一个坏主意。我不认为 github 会这样做,但保存起来似乎更好。
M
Matthew Sandoz

Camel case 的问题在于,通常对单词有不同的解释——例如,checkinService 与 checkInService。根据 Aaron 的回答,如果您有许多类似名称的存储库必须不断检查创建您关心的存储库的人是否使用了大写和小写的某种细分,那么自动完成是很困难的。避免大写。

他关于破折号的观点也是明智的。

使用小写。使用破折号。请明确点。稍后您可能会发现您必须区分相似的想法 - 即使用 purchase-rest-service 而不是 service 或 rest-service。始终如一。考虑各种 GIT 供应商的使用情况——您希望如何对存储库进行排序/分组?


您的答案涉及两个重要问题,而最佳答案却没有。
忘记是 checkin-service 还是 check-in-service 比忘记是 checkinService 还是 checkInService 有什么好处?
对于非母语人士来说,骆驼案也更难。
@BenAveling 实际上没有。骆驼案似乎更容易正确阅读。 citeseerx.ist.psu.edu/viewdoc/…
@user625488 您的回答与 BenAveling 论点是正交的。上述论文讨论了阅读正确性的训练。如果有的话,前提条件(非母语者和培训)强化了非母语者需要训练以更好地阅读标识符的想法。在没有训练的情况下,camelCase 的表现不如snake_case(图 2)。令我困扰的是,研究似乎没有考虑相同的拼写而是不同的含义,正如这个答案所示(表 1)。
D
Dennis

lowercase-with-hyphens 是我在 GitHub 上最常看到的样式。*

lowercase_with_underscores 可能是我看到的第二受欢迎的样式。

前者是我的首选,因为它可以节省击键。

*轶事;我没有收集任何数据。


连字符还具有 SEO 优势。这可能不是主要考虑因素,但由于我们有点谈论 URL,所以它是相关的。
连字符还有另一个优点:它们更容易在带下划线的超链接中被发现(下划线可能很容易被误认为是空格)。
正如您所提到的,很难收集数据,但我去了 github.com/trending/developers,只看到了前面提到的样式:lowercase-with-hyphens
C
Community

在不偏爱任何特定命名选择的情况下,请记住 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?”),但这是一个单独的问题。


好点子。但是,在客户端修复 repo 名称在一定程度上证明了命名约定会有所帮助。你不觉得吗?如果它首先遵循约定,为什么要修复它?也许maven对我影响很大。
@AdrianM 我的观点是:是的,命名约定很有用,但它与 Git 或 GitHub 无关,与您想对特定存储库执行的操作无关。因此,您的问题的答案是“不,没有 git 存储库的命名约定”。
S
SteveW

也许这只是我的 Java 和 C 背景显示,但我更喜欢 CamelCase (CapCase) 而不是名称中的标点符号。我的工作组使用这样的名称,可能是为了匹配存储库包含的应用程序或服务的名称。


这篇文章很少,这不是我个人的偏好,但他仍然提到了一个好处,Java 中的项目名称是驼峰式的,并且在一致性方面有一些安慰。我们确定这里的反对意见不仅仅是一种命名偏见吗?
同意。其他答案讨论了camelCase的缺点,但是在Java世界中,无论如何决定camelCase更好是完全合理的……尤其是对于对Windows世界一无所知的项目。
迂腐公益公告:PascalCase 不是 camelCase。
@MarredCheese 我公司有一个人坚持称其为“上骆驼案”,我想把午餐扔给他。
A
Adam

如果您计划创建一个 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 上的包相同。