ChatGPT解决这个技术问题 Extra ChatGPT

Is there a naming convention for git repositories?

For example, I have a RESTful service called Purchase Service. Should I name my repository:

purchaserestservice purchase-rest-service purchase_rest_service or something else?

What's the convention? How about in Github? Should public repositories follow some standard?

This blog post might be of some use gravitydept.com/blog/…

A
Aaron Digulla

I'd go for purchase-rest-service. Reasons:

What is "pur chase rests ervice"? Long, concatenated words are hard to understand. I know, I'm German. "Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung." "_" is harder to type than "-"


I don't (really) understand, but didn't you miss an S in ...auschreibung...?
@adimauro: It's an application as for an open position as an assistant to fill in forms for captain patents of Danube steamboats.
Any particular reason you don't prefer camelCase? That's my go-to common-item naming convention since it uses no special characters.
@10gistic the repo name is often seen in URLs (e.g. on github) that may be case insensitive or even converted to lower case, and for this reason camelCase is a bad idea. I don't think github does this, but still seems better to be save.
M
Matthew Sandoz

The problem with camel case is that there are often different interpretations of words - for example, checkinService vs checkInService. Going along with Aaron's answer, it is difficult with auto-completion if you have many similarly named repos to have to constantly check if the person who created the repo you care about used a certain breakdown of the upper and lower cases. avoid upper case.

His point about dashes is also well-advised.

use lower case. use dashes. be specific. you may find you have to differentiate between similar ideas later - ie use purchase-rest-service instead of service or rest-service. be consistent. consider usage from the various GIT vendors - how do you want your repositories to be sorted/grouped?


Your answer touches on two important issues the top answer doesn't.
How is forgetting whether it's checkin-service or check-in-service better than forgetting whether it's checkinService or checkInService?
Camel case is also harder for non-native speakers.
@BenAveling Actually no. It seems that camel case is easier to read correctly. citeseerx.ist.psu.edu/viewdoc/…
@user625488 your response is ortogonal to BenAveling argument. The mentioned paper discusses the training on correctness of reading. If anything the preconditions (non-native speakers & training) reinforce the idea that non-native speakers need to train to read better the identifiers. Without training, camelCase underperforms snake_case (Fig 2). And it bothered me that study seemed to not consider same spellings but diff meanings as this answer shows (Table 1).
D
Dennis

lowercase-with-hyphens is the style I most often see on GitHub.*

lowercase_with_underscores is probably the second most popular style I see.

The former is my preference because it saves keystrokes.

* Anecdotal; I haven't collected any data.


Hyphens also have SEO advantages. This might not be a major consideration, but since we're kinda talking about URLs, it is relevant.
Hyphens also have another advantage: they are easier to spot in underlined hyperlinks (where underscores might be easily mistaken for spaces).
Hard to collect data as you have mentioned, but I went to github.com/trending/developers and saw only the former style that has been mentioned: lowercase-with-hyphens
C
Community

Without favouring any particular naming choice, remember that a git repo can be cloned into any root directory of your choice:

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

Here repo.git would be cloned into the myDir directory.

So even if your naming convention for a public repo ended up to be slightly incorrect, it would still be possible to fix it on the client side.

That is why, in a distributed environment where any client can do whatever he/she wants, there isn't really a naming convention for Git repo.
(except to reserve "xxx.git" for bare form of the repo 'xxx')
There might be naming convention for REST service (similar to "Are there any naming convention guidelines for REST APIs?"), but that is a separate issue.


Good point. However, fixing the repo name on the client side somewhat proves that having a naming convention would be helpful. Don't you think? Why fix it if it followed a convention in the first place? Maybe maven has influenced me a lot.
@AdrianM my point is: yes, a naming convention is useful, but it has nothing to do with Git or GitHub, and everything with what you want to do with that particular repo. So the answer to your question is "no, there isn't a naming convention for git repositories".
S
SteveW

Maybe it is just my Java and C background showing, but I prefer CamelCase (CapCase) over punctuation in the name. My workgroup uses such names, probably to match the names of the app or service the repository contains.


This post is sparse and it's not my personal preference, but he still is mentioning a benefit, that the project names in Java are camel case and there's some comfort in congruency. Are we certain that the downvotes here aren't just a naming bias creeping in?
Agreed. The other answers discuss the disadvantages of camelCase, but in the Java world, it would be entirely reasonable to decide camelCase is better anyhow... especially for projects blissfully ignorant of the Windows world.
Pedantic public service announcement: PascalCase is not camelCase.
@MarredCheese there's a guy at my company that insists on calling it "Upper camel case" and I want to throw my lunch at him.
A
Adam

If you plan to create a PHP package you most likely want to put in on Packagist to make it available for other with composer. Composer has the as naming-convention to use vendorname/package-name-is-lowercase-with-hyphens.

If you plan to create a JS package you probably want to use npm. One of their naming conventions is to not permit upper case letters in the middle of your package name.

Therefore, I would recommend for PHP and JS packages to use lowercase-with-hyphens and name your packages in composer or npm identically to your package on GitHub.