547

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

  1. purchaserestservice
  2. purchase-rest-service
  3. purchase_rest_service
  4. or something else?

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

Vertexwahn
  • 7,709
  • 6
  • 64
  • 90
Adrian M
  • 7,047
  • 7
  • 24
  • 26
  • 5
    This blog post might be of some use http://gravitydept.com/blog/devising-a-git-repository-naming-convention – PHeiberg Aug 14 '12 at 07:31

6 Answers6

648

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

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

  2. "_" is harder to type than "-"

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • 1
    Personally, I prefer this too but apparently based from the answers here, there seems to be no convention... yet. – Adrian M Aug 14 '12 at 10:10
  • 1
    So, according to Google, that means: 'Danube steamboat ride captain patented fill out-tender wizard provide senior'. Huh?! :) – adimauro Jun 12 '13 at 15:31
  • 11
    @adimauro: It's an application as for an open position as an assistant to fill in forms for captain patents of Danube steamboats. – Aaron Digulla Jun 12 '13 at 15:59
  • 7
    Any particular reason you don't prefer camelCase? That's my go-to common-item naming convention since it uses no special characters. – 10gistic Jun 13 '13 at 18:25
  • 54
    @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. – jdg Aug 07 '13 at 15:48
  • 2
    When you create a new repository on BitBucket, it converts the name to hyphenated lowercase alphanum in the URL while keeping the original (upper/lower, spaces etc.) in the account data. For example "JIRA Issue Summary Conventions Plugin" becomes https://bitbucket.org/melias/jira-issue-summary-conventions-plugin – tocker Dec 11 '13 at 10:16
  • 1
    What about `purchaseRestService` or `PurchaseRestService`? – joshreesjones Apr 13 '14 at 21:40
  • 1
    @mathguy54: Those are Java conventions. They work well as long as you use a file system which is case sensitive. If you use Windows, the I would stay away from it: One day, someone will rename "foo" to "Foo" and git will be confused. http://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git – Aaron Digulla Apr 14 '14 at 08:51
  • 27
    Guys in the GitHub use hyphens. http://habrastorage.org/getpro/habr/post_images/d34/331/a8d/d34331a8d0a6f47b983a1a9d79845b03.png – airato May 06 '14 at 13:38
  • @airato: The screenshot shows a list of branches not repositories. The naming conventions of branches may be another than for repositories. – Tsunamis Aug 24 '16 at 08:58
  • 3
    It's an application ("stellen-bewerbung") to an announcment ("ausschreibung") which looks for an assisstant to fill in ("ausfüllungs-assistent") captains patents ("kapitäns-patent") to run steam ships ("dampfschiff-fahrt") on the river Danube ("Donau"). – Aaron Digulla Sep 19 '19 at 08:06
  • 2
    So, we should follow `kebab-case` – Parag Meshram Apr 27 '20 at 07:07
  • paths in URLs are case-sensitive. It's in the spec. host names are not. – Reid Ellis Aug 19 '20 at 13:57
  • @jdg regarding camel case, Github does not care when creating a repo the camel case style. So why bother? I will now stay with my "test" repo CamelCase. – Timo Nov 30 '20 at 09:36
  • Number 2. is completely opinion based. No character is inherently harder to type. – Damien L Sep 14 '21 at 14:06
  • @DamienL If you need to press two keys instead of one, that's harder to type, especially when you're disabled by people who are "normal". – Aaron Digulla Sep 18 '21 at 17:47
  • Agreed, anything that requires two keys instead of one is harder to type. – Damien L Sep 20 '21 at 12:33
  • And that number of keys that you need to press is completely opinion based. – Damien L Sep 20 '21 at 12:41
  • 2
    But "-" is harder to copy than "_" (simply select with double click). – Lucas Lopes Oct 23 '21 at 15:38
  • _"I know, I'm German. 'Donaudampfschifffahrtskapitänspatentausfüllungsassistentenausschreibungsstellenbewerbung.'"_ - LOL from 2022 :) –  Jan 26 '22 at 00:21
  • 1
    The people at GitHub seem to prefer hyphen over underscore, looking at their repo names - https://github.com/orgs/github/repositories?type=all – Mark Ingram May 06 '22 at 16:18
  • Choosing a name because it takes a fraction of a Joule less energy to type feels like a subtle parody illustrating the dangers of premature optimisation :). Especially given that you may _only_ type the repo name exactly once (when you first create the repo). – Jack Kelly Jul 21 '23 at 07:50
  • Names are _read_ far more often than they're _typed_. Especially GitHub repo names: I don't know about you, but I copy-and-paste repo names when I first clone repos. Choose a name that makes sense to the reader. Don't choose a name because typing it will save you 0.05 Joules over your entire lifetime :) – Jack Kelly Jul 21 '23 at 07:59
153

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.

  1. use lower case.
  2. use dashes.
  3. be specific. you may find you have to differentiate between similar ideas later - ie use purchase-rest-service instead of service or rest-service.
  4. be consistent. consider usage from the various GIT vendors - how do you want your repositories to be sorted/grouped?
Matthew Sandoz
  • 1,631
  • 1
  • 10
  • 3
  • 8
    Your answer touches on two important issues the top answer doesn't. – Will Beason Jun 26 '15 at 14:44
  • 11
    How is forgetting whether it's checkin-service or check-in-service better than forgetting whether it's checkinService or checkInService? – MarredCheese Apr 09 '19 at 19:37
  • Camel case is also harder for non-native speakers. – Ben Aveling Jan 10 '20 at 03:10
  • 3
    @BenAveling Actually no. It seems that camel case is easier to read correctly. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.158.9499&rep=rep1&type=pdf – user625488 Apr 14 '21 at 07:03
  • 1
    @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). – Andre Figueiredo Mar 13 '22 at 03:20
  • @Andre Figueiredo Quoting from that article: "although those without training take longer to recognize identifiers in the camel case style, all subjects are more accurate when identifying a camel-cased identifier." What's the point of reading an identifier if you don't read it correctly? To put things in a funny way, camel case slows you down while underscores and dashes allow you to make mistakes faster. IME, it's overall always cheaper to make fewer mistakes, even if you make them slower. Facebook seems to have had the same experience, since they gave up on "move fast and break things". – user625488 Mar 14 '22 at 04:50
104

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.

Dennis
  • 56,821
  • 26
  • 143
  • 139
  • 16
    Hyphens also have SEO advantages. This might not be a major consideration, but since we're kinda talking about URLs, it is relevant. – Michael Scheper Mar 31 '17 at 14:39
  • 40
    Hyphens also have another advantage: they are easier to spot in underlined hyperlinks (where underscores might be easily mistaken for spaces). – Jeroen May 11 '18 at 15:05
  • 4
    Hard to collect data as you have mentioned, but I went to https://github.com/trending/developers and saw only the former style that has been mentioned: ```lowercase-with-hyphens``` – SaTa Jun 26 '19 at 17:11
27

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 5
    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. – Adrian M Aug 14 '12 at 09:22
  • 1
    @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". – VonC Aug 14 '12 at 09:37
  • Could you elaborate on the .git form? Wouldn´t it be cool if my repo folder had the .git extension so I could easily tell which folders are git repositories? – Jonas Äppelgran Aug 14 '22 at 20:54
  • 1
    @JonasÄppelgran Generally, (non-bare) Git repositories can be cloned in a git folder, dedicated to all your Git repositories. But *bare* repositories folder end with `.git` by an old convention (see "[Introduce `is_bare_repository()` and `core.bare` configuration variable](https://github.com/git/git/commit/7d1864ce67d83485cf5cbc8c90fc170ee884ef16))": "If it is `".git"` or ends with `"/.git"`, then it does not look like a bare repository, otherwise it does". But it is only a convention. You can adopt the one which makes sense to you. – VonC Aug 14 '22 at 21:15
17

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.

SteveW
  • 387
  • 2
  • 5
  • 6
    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? – eremzeit Sep 03 '16 at 09:01
  • 2
    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. – Michael Scheper Mar 31 '17 at 14:42
  • 32
    Pedantic public service announcement: PascalCase is not camelCase. – MarredCheese Apr 09 '19 at 19:32
  • 3
    @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. – Sinaesthetic Sep 01 '20 at 17:30
  • @MarredCheese Get out-pedantried: it was originally CamelCase and lazyCamelCase. But people ended up saying "camel case" to refer to both and/or to omit the "lazy" since it was clear in-context (if you already knew the names, but misleading if you were learning the terminology from the context... which is how most learning happens). It only became popular to call CamelCase PascalCase more recently, once it became popular to call lazyCamelCase camelCase. – mtraceur Jul 03 '23 at 07:33
6

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.

Adam
  • 25,960
  • 22
  • 158
  • 247