So we've got snake_case and camelCase when it comes to code, and when it comes to filenames there's a third option we don't talk about as much because it's not usually available in code: dash-case. I've favored snake_case in both code and filenames for a long time because "it looks more like a space". And I do think that has a very real, practical benefit to readability, at least compared to camelCase. CamelCase, on the other hand, takes up one less column, which has a benefit in reducing the amount of line-wrapping needed, but I think that's much smaller.
Lately I've been starting to think more about speed. With filenames, dash-case is a keypress faster than snake_case. (CamelCase is also a keypress faster.) Typing a name one keypress faster doesn't matter so much in code, where you spend most of the time reading rather than typing, but for filenames, which you spend a lot more time typing, it's more significant. This might be convincing me to start using dash-case in filenames. I'm not sure yet.
So my question is: besides personal accustomization/stuff, does anyone have any other pros or cons to point out of any of the three options?
Discussion (37)
Eye-tracking study finds that snake_case is more readable than camelCase.
I like how Ruby uses snake case for typical variables and methods and UpperCamelCase for objects and UPPER_SNAKE_CASE for constants. The convention of using the different cases to signify different things makes for a lot of good legible code IMO.
TIL!
I agree with all of this, but also feel kebob case is just easy to read as snake case. I tend to prefer it for file names.
It's a good thing feelings don't trump observations found in scientific studies. Also, not everyone is the same, it turns out.
I'm just waiting for a language to come around that codifies these conventions as errors so the style arguments die.
Don't forget SCREAMING_SNAKE_CASE.
Okay, it's terrible for anything but naming constants. I just love the name.
I don’t have a dog in the fight, except this.
I always try to program in the conventions of the language I am using.
Dashes for CSS classes. CamelCase for JS, except title case for classes. Python is underscores. Ruby is just a mixed bag. Dashes for html attributes.
To me that makes readable code. And I think the conventions are better for the community. Historically when these things change, it’s something that gets adopted and accepted. In recent years for JavaScript this seems to be AirBnB or Prettier.
Clojure / Lisp also seems to use dash-case (i.e. kebab-case).
I think Python's
snake_caseis an outlier, despite being slightly more readable thancamelCase. So, I'll stick withcamelCase. camelCase is more standard.kebab-case is very similar in readability and parsing to snake_case, I think, but it is much less supported in programming.
However, I tend to use kebab-case in TypeScript filenames (in Python filenames, I use snake_case).
UPPER_SNAKE_NAME is also very popular for constants.
I mean, it works for rust-lang. I like kebab-case as well, coming from a .NET/PowerShell background.
In my case, I use
camelCaseall the time.My API dev is using
snake_case, so most of the time I just harass her for using it (we still friends). And when it comes to do some code fixes in her APIs, I refactor it tocamelCase.I can't think there are pros or cons to this specific subject. These two options are the only possible ways to code in, its just a matter of preferences.
Lol, that sounds like a big source of time waste :P you two should really agree on one.
Yeah we’re still working on it 😂
So during a refactor you introduce API breaking changes everywhere? You sound awful to work with.
Thanks!! I know right? Thanks God you’re not working with me ha? Mind your business son.
You posted your story in a public forum. Responses to your passive-aggressive co-worker relationship should be expected.
You replied to a public forum post, You expected to hear something you don't like. This is the life.
Forgot to mention: one thing that really bugs me about JS/JSON is that the JS convention is lowerCamelCase, but the JSON convention is snake_case. Having these two be different really throws me off a lot, given how interrelated they are.
Can I ask where you’ve seen snake case as the standard for JSON? I very rarely see it, and I’ve definitely never seen an official recommendation for it.
Google APIs (place search/geocode stuff), the API of the web service I work on at my job (Awning Tracker), and... huh. Now that you mention it, I can't think of any other examples. I guess I haven't seen as many different JSON APIs as I'd started to think (I shouldn't count my own website lol). I just found out that apparently the standard is supposed to be camel. TIL.
Interesting. I wonder why Google chose to do that. Maybe it makes it more consistent since they do a lot of their APIs for multiple languages, and they picked a snake language as their favorite.
IMO, it depends.
kebab-casein common.camelCasein common.snake_casein common.kebab-casein common. It also match to the HTML naming convention.It varies strongly from language to language.
Java has a de facto styleguide that says variables should be camelCased and classes should be CamelCaps (and other "rules" and conventions - POJO conventions comes to mind).
Python has PEP8 that also has their saying: classes should be CamelCaps and variables, snake_case (both, preferably - exceptions apply).
PEP8 is a interesting reading.
@yujiri8 mentioned JSON has a standard and, AFAIK, there isn't an official one. The JSON.org docs says that properties names should contain only 'a'..'z', 'A'..'Z' and '_'. There's also no indication on ECMA of a standard.
Kebab case is, IMHO, confusing as it would be mistaken for a minus sign (and probably incompatible in some languages).
My take here is: follow the language convention. It's easier on the eyes of people that has more time/experience on the language and less work for the linter (if you use one - PS: you should).
In some Python libraries, like PyQt, uses CamelCase (PascalCase).
I'm late to this party, but I've never cared as long as it's consistent. I like languages with either built-in code formatters or at least widely accepted styles, so that I know what I'm in for when I open someone else's code. One less thing to think about.
I’m a fan of kebob case, especially with file names.
Personally I like snake_case, but sadly I think personal preference is the least important POV:
1º what the existing codebase use
2º what the PL "suggest" (fight with automated formaters is wasted effort)
3º finally what I like :)
feel free to hate the former programmers if 1º is different than 2º.
I use all of them, depending the language I am using.
i.e
in C++ and Rust I use snake case
in C#/js variable names I use camelCase
in Angular filenames I use dash-case
everything has its place
How about nut case? It's when you mix as many styles as possible and let chaos flow through the codebase
Did you know that dash-case is also called kebab-case?
No, but I do now :)
dash-lower-case for me :) no stupid case switching ever
Problem with dash-case is that double clicking will not select the entire name.
Ooh, that's something that never even occurred to me. I don't really use double-clicking to select text, but it's an interesting point. A lot o environments can customize what counts as a word divider (eg. xfce4-terminal), but I guess that might mess up other things.
That doesn't work in most languages, though, does it? What do you do in languages that don't allow
-in names?Personally I like CamelCase. In the language I work in, however, dash-case* was quite common to use. The main disadvantage is that a dash-cased word cannot be selected by double clicking it. If you do it, only one side of the dash is selected.
One thing that's also a consideration here is that with kebab case, in your text editor you lose the option to select the whole variable name as well as chunks of it, like you can with snake case and camel case. For this reason I use snake case in my CSS classnames and IDs.
I vote for SaRCasM_cASe, it's the best of all worlds.