Interesting results! Underscores do have two built-in caveats that offset the recognition benefit somewhat: more characters to type, and an awkward key to hit (shift + hyphen).
To overcome this issue, I switched to the Dvorak keyboard layout and use Karabiner Elements to remap some of my keys. The result is that I can type underscores on the home row and parenthesis on my shift keys (tap == parenthesis and hold == shift). This has eliminated the RSI pain I used to feel from these hard-to-reach keys.
Came here to say this. Underscore/dash is on the home row in Dvorak, making snake_case/kebab-case way more natural to type.
Cool trick about mapping shift keys with Karabiner-Elements. I do that with my caps lock to create a "hyper" key: tapping it brings up Alfred, using it in a chord is "hyper", and long pressing caps lock maintains its default behavior.
I'll second that, kebab-case is easy to type, has nice readability, and fits well with regular English constructions like case-sensitive, human-sized, looking-glass, and so on.
The problem I've had with kebab case is cross language / devops systems. Some languages and systems don't like kebab case whereas snake case appears more compatible eg. Rpc calls to a named (kebab or snake endpoint).
maybe it is some sort of status thing. since people have to be able to afford a fancy keyboard with a shift key to use camel case or underscores, it shows they can afford nicer things than us kebab-cases.
more seriously, it is the unfortunate fact that a lot of systems interpret named-thing and named minus thing. many people don't have the option of using kebab-case. it isn't a good style because it is often impossible to use. which is unfortunate because it is more ergonomic.
The fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. Readability, ease-of-typing, parallel with the way it's used in (Romantic) natural language. If I were writing a new language I intended to popularize this would be one of the features I would emphasize.
Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
Infix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
That is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much.
Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
> Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes.
Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen").
Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
Distinguishing unary minus from binary minus is not done by spacing in parsers. Most modern language parsers ignore whitespace except where it would cause the concatenation of two identifiers (or in the case of languages like python or nim, where it is at the beginning of a line).
I know this for a fact since I've studied their grammars.
Infix notation and - are really the reasons why nobody does this, some people like to use spacing to indicate precedence too (writing code such as "a - 1*g") so it would break some workflows and realistically having a language which is whitespace agnostic except for identifiers AND the minus operator just seems too irregular for people to commit to it.
That's why I said most. Obviously there exist languages, such as elm, where this is not the case, but in the case of those languages, the teaching literature (as is the case with elm) explains these things. Most languages don't do this precisely because their designers made the judgement call that the additional parsing complexity (both for the actual parser and the human) outweighed the benefits of allowing you to have minuses in identifiers.
I think you're maybe just a little confused, or I'm missing something. Kebab case is in general not viable to implement unless you have very a special/quirky syntax, because there is no way differentiate to `a-b` from `Id("a-b")` and `Subtract(Id("a"), Id("b"))` from syntax alone. Now, there are of course options that introduce trade-offs.
First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language. This is very useful because then you can have identifiers like "a+b", or even identifiers like "a+[b+c-d]" etc... As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that, well now you're not allowed to condense arithmetic operations. This may or may not be a problem, depending on the programming language designer. When you said:
> I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
I'm guessing your opinion is that you're ok with this trade-off. Fact of the matter is that this a very fringe syntax for any programming language to have. As an Agda programmer, I like it, and it is useful, but I'm not convinced something like this would find mass appeal.
The last option I'm aware is to have semantic differentiation. When you find a statement like "c = a-b" you need to ask two things. One, are there identifiers "a", "b" and "a-b". If "a-b" exist and "a" or "b" doesn't exist, you're all set. If all three exist, second question is, are "a" and "b" subtractible? If the answer is yes then programming language designer can choose to prioritize "a - b" over identifier "a-b". Alternatively, you can always choose to prioritize identifier "a-b" as long as it exists. I'm personally not aware of any language that implements something like this, however I have implemented toy languages that go through this, it's pretty easy. It's a matter of making the decision to introduce this type of complexity into your language.
All in all, although I love kebab case, in order to have it in your language you need to make pretty significant trade-offs. Given this, I'm not surprised any mainstream non-lisp-like language doesn't have it.
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
This is a gross error. In your sense, Lisp does not even have operators, only identifiers. The reason there is no confusion between "(- a b)" and "(-ab)" is the spacing that separates the three identifiers in the first case.[1]
Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does".
[1] However, Lisp does have a potential problem with identifiers that begin with a hyphen, due to the need to support literal numeric values like -3. Thus the Common Lisp decrement function is named "1-" despite not returning the value (1 - operand).
> Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does".
I assume you're talking about GP's third paragraph here. Assuming that's true, I think you've misinterpreted it: GP was talking about using infix operator notation, which is most certainly not what Lisp does.
Lisp will treat (a - b) as 5 tokens, just the same way it will treat (- a b) as 5 tokens. Infix operators are completely unrelated to this problem. What lisp is doing is determining tokens by reference to spacing (the parentheses don't need to be spaced; I believe they are reader macros but in any event they are special-cased) and then acting on the tokens. What C is doing is not that; the concept is that you eliminate all spacing before you decide what the tokens are.
So in C, there is no such thing as "a - b", only "a-b", and that's why "a-b" cannot be used as an identifier.
If you want to write your lisp in infix notation, you can, but it will remain true that (a - b) is a list with 3 elements and (a-b) is a list with 1 element, which is what matters here.
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
> Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language.
is kinda not good, Lisp allows "-" in names the same reason as Agda: it tokenize by spaces (correct me if I'm wrong). This may seem as a gross error for one, and an only implied who cares error which is even true if taken word-by-word, for an other.
(Hot damn, that was a super thorough/thoughtful reply in a short amount of time.)
You're spot on about the quirky syntax, but I don't think it's as serious a trade-off or addition in complexity (or even a change), given that:
- (IIRC) many style-guides/formatters already enforce spaces between binary operators and their operands (but especially identifiers) and in my super-subjectively-opinionated opinion you should already be doing that even without a formatter
- I don't feel particularly strongly one way or another about any other special characters like "+", so really in this case I'm only considering the dash
- Requiring the dash be between alpha/alphanumerics makes it play nice with unary operators
- The language would be terrible for code-golfing, but that's a relatively niche application I'd definitely consider worth spurning
> As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that
I would say the trade off is variable names like “a+b” themselves. I fail to see any reason why would I want something like that, like even in Math where the grammar is very hand-wavy to accommodate human parsing you would be insane to write that (though to be fair, math does have their own share of problem with identifiers, enumerating all the letters in different alphabets is not a sustainable solution)
Why not just give it some temporary name, like ‘t’, supposedly it is only used in a very tight scope. Haskell and similar languages often do these things with `let in ..` or `.. with t=a+b`.
Not really better at all, but I feel this is a bit contrived example. If it really is just numeric addition that just let the compiler do its job, otherwise I’m sure there are better names for whatever you actually try to do. And, random helper variables are a thing even in math, you don’t name the thing the way you calculate that thing because then you don’t spare any character.
One could also not have subtraction but simply negation, so instead of a-b being subtraction, one could have a+-b. It probably already works in most languages. Doubt it would be embraced.
Everybody forgets about shell scripts! Bash allows dashes in executable names (how it couldn't) and in function names, but not in variable names, at least not without a lot of effort.
Make your language syntax require whitespace around arithmetic operators, and then we can finally live in a glorious paradise of kebab-case and `foo/bar` for namespaces.
I mean, not even a bad idea. I would honestly prefer operators to be more explicit like a-variableanother-varsomething-else. (EDIT: HN removed my emojis, but imagine a plus/minus emoji inbetween ids :( )
With a good font it would basically look similar to what a good IDE with syntax highlighting already does (different color for operators).
I think this would be a bad idea because emoji are hard to type.
This might be a bit old school but I prefer things limited to plain ASCII. There's only so many keys on a keyboard and want to be able to touch type everything without thinking or looking at a special emoji bar.
That I absolutely agree with, but I think it is about time we let go of “programs as plain text” axiom. With good tooling/IDE — which are already sort of visual editors only converting to and from to plain text on save — you could enter a ‘+’ and get autocomplete show the “emoji +” as an option for example. Because the actually important question to ask here in my opinion is “what is the easiest way to read/comprehend programs”, and we seem to have implicitly agreed that syntax highlighting is already a must (which works on even not yet valid program text!). Slightly more reliance on tooling doesn’t seem too bad to me.
I actually have a toy language that uses emojis for keywords, allows me to reduce tokenizing to basically "split by whitespace, split into runs of characters of the same class (every character is its own class except for [A-Za-z0-9_-] which make up a single class), then post-process tokens for finer distinctions". Strings are somewhat more painful, but using \q instead of \" to escape the double quotes helps.
I’ve always liked the readability, but interaction is a problem when many UIs treat the hyphen as a break character. Most (all?) browsers do, and even some (albeit not good) IDEs cannot be configured otherwise. When you’re in a hurry, it’s easy to miss a bit off the end.
Alas, that doesn't seem to be a general solution. Sure, it doesn't cause line or selection break in my IDEs, nor does it line break in browsers, but it's still a selection break in everything except IDEs (such as all the web and chat services developers use to talk about code), it's harder to type, and as a homoglyph it's super problematic to grep or index identifiers that use it. This last consideration could potentially even increase an attack surface.
I'd suggest that it's feasible if we lived our entire developer lives inside a monoculture that adopted it, but that just ain't reality.
This all adds up to "why I do not kebab my identifiers".
I had never heard of kebab-case before as kebab refers to cooked chunks of meat.Soon it dawned that shish (meaning skewer) was meant, as in shish-kebab-case. Sorry to be that guy.
Infix has nothing to do with it. - refers to the subtraction function regardless of whether it is placed in prefix or infix position. Infix will trigger a type error, not a syntactic error — it will tell you that e.g. it cannot call a fixnum. Lisp quite ordinarily requires function names to be separated from their arguments by spaces, which is just a special case of the rule that atoms need to be separated by spaces. That’s all.
In many Lisps (+ + +) means this: call the function named + on the two values from the variables named +. The function is then a function object and the values of + can be anything they are currently set to.
Thus + serves more than one purpose: function or variable and both may be different values.
Thus the position actually matters.
What we have below the Lisp syntax are s-expressions: nested lists of symbols and other objects. In s-expressions, symbols need to be separated by whitespace, parentheses or possibly by some special character type (-> terminating character). Characters like +, -, /, *, _, ... are valid characters for any symbols.
Thus Lisp does not require functions to be separated by characters but symbols. That's a part of the reader mechanism for reading s-expressions (-> symbolic expression).
Significant syntax shouldn't be invisible to the human reader. If a parser can't parse it without special space characters, then a human will also tend to have trouble parsing it.
I don't see as well as I used to and snake_case is much easier for me to read when scanning through code than camelCase.
This may be why I tend to gravitate towards languages like Elixir and Ruby, who prefer snake_case, and away from languages like Go, which use camelCase.
I mean doesn’t it make you want to make ___________super_ultra_private, with an accessor that corrupts the filesystem and hangs if you so much as look at it?
That sounds good, but we might need a class attribute that disables filesystem corruption in case we need to access `___________super_ultra_private` somewhere
I don't hate leading underscores on _private_function or _class variable, in fact I think it's a great way to semantically signal intent
The double underscore for __super_private_function doesn't make much sense to me though. I can't see a reason why this shouldn't just be a single underscore, especially when __double_underscore__ signals very important python internals
The leading double underscore functions differently from a leading single underscore in this case:
> Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped.
I do find your straw man for the camel case amusing. Specifically, "versus compared to" doesn't parse well and hurts my ability to read it.
That said, data in this study is interesting for being data and a replication. I don't know that I've given much thought to liking one style over the other in a long time, neat to see the impact it can have.
Directly to your last point, I do greatly prefer single word names, if they can be used. So, `candidates` over `candidateList` or `candidate_list`.
This haunts me. It seems almost as good as snek_case but doesn't require a Shift. If we're not Shifting the letters, why are we shifting the -s? My OCD. (Or my autism?) Help.
Another consideration: whether the program you're typing in will stop at underscores or hyphens when using Ctrl + Shift + Left/Right Arrow when highlighting. If I want to highlight `this_variable_with_a_long_name` without using the mouse, it's going to be a pain if I have to hit the left arrow key six times instead of once. (Frustratingly, it varies from editor to editor.)
Because many languages don't require whitespace between symbols (e.g. x) and operators (e.g. +). So in Python, x+3 is valid (x plus three). As is x+y. And x-y. So how does the interpreter/compiler know if coffee-bean is a single variable, or an operation (coffee - bean) between two variables?
The reason we (most of us) can’t have kebab-case is the same reason it mostly occurs in lisps and other declarative syntaxes: infix operators. ie if you can have identifiers or keywords like-this and you can also have subtraction like-this, you have some serious syntax ambiguities to deal with.
As far as keyboard navigation around partial or whole words, I find it really helpful to have separate keybindings. For me (on a Mac so keyboard layouts matter), opt+left/right moves a “whole word” (as in to the nearest non-word character) and ctrl+left/right moves to the nearest internal word boundary (where boundary is mostly arbitrary; in bouncyCase it moves to the nearest non contiguous case change, in any-punctuated_case it moves to the nearest punctuation).
Agree it’s frustrating how much this varies by editor, but being able to configure the behavior is one of my first checks when deciding if I’ll use the editor at all.
kebab-case is all very well as long as a hyphen is not treated as the 'minus sign'
Many years ago, I was programming in COBOL, where kebab-case is the norm. For a while there I was programming in both "C" AND in COBOL. That was a nightmare, I invariably used the wrong syntax for my variable-names, as both languages used incompatible syntax for those variable-names.
Having to press shift shouldn't matter much except when you are introducing a new identifier because your autocomplete should kick in after you type the first couple of characters. (You are using an IDE, right?)
Remember those keyboards with a split space bar? I don't know what they were meant for, but I always thought it would be cool to map one of them to underscore. Never had such a keyboard myself though.
I personally like the underscore because it is always the same combination while Caps are combinations all over the place and you have to choose the most convenient shift key, left or right.
I wonder if novelty matters. This "versusComparedToCamelCaseBouncingUpAndDown" is certainly harder to read but I also found it harder to read than all my CamelCase identifiers in code.
For me OriginalAmount or AdjustmentFees are just one word each.
Whatever the standard is for the language. Unless we're in a language without a standard (cough cough PHP cough cough). I work in a real snakecase mixed with camelcase PHP codebase at seemingly random intervals. Worst part is that this codebase started only a few years ago.
Snake is my preferred. The Python/Rust use of snake case and Pascal case for their respective purposes is my favorite.
I actually did set up our linter but can't enforce the casing since so much of the codebase is all over the place and leadership didn't want to take any risk with an automatic conversion :shrug:.
It is indeed common for new developers to not know or care about it, but most professional shops I've been to adhere to it unless they're working on very legacy code.
Huh, thanks for the link. I swear that when I read that document (or a similar PSR) about a year ago, it specified that it didn't take a stance for method names (or maybe regular function names). I wonder why I thought that or if I read it someone else.
I prefer snakecase, but I just use whatever the standard is for the language I'm using, or the project if it already exists. Staying consistent is most important for these kinds of things.
In ruby anything that starts with a capital is a constant, but PascalCase is only used for ClassNames and ModuleNames, and ALL_CAPS_SNAKE_CASE = "is used for constant values". Unless you are some kind of monster anyway.
I wish a language was designed to allow identifier with space in them without quotes. That is the most readable. But I don’t know the consequences to the rest of the grammar
Underscores are visually very similar to spaces. Their major problem is unrelated to their appearance - it's that you have to use a key combination in order to type them on a standard keyboard.
The obvious solution would appear to be to use better keyboards, but I don't even see anyone suggesting that.
But note that the lisp identifier style, words-separated-by-hyphens, is better than using underscores despite being less legible. It's purely a matter of how easy it is to type the separator. ("Standard" languages don't allow hyphens in identifier names because they want to allow subtraction without requiring a space between the subtraction operator - and the two operands. In Lisp, spacing around an operator, including the subtraction operator, is required. You could go a long way in a C-like language by just requiring spacing around operators and immediately being able to allow hyphens in identifiers.)
> Their major problem is unrelated to their appearance
Shift key is a problem for all the shifted only chars. Their major problem is appearance: a single underscore '_' vs underscores '__' . Concatenated glyphs are hard to discern due to only distinguisher being width.
I have no idea what you're trying to say. You just compared underscores with underscores; relative to underscores, underscores cannot even theoretically have any problems at all.
Use non-breaking space for identifiers and regular/breaking space as a delimiter? Admittedly you'd want an editor that clearly showed the difference and made the former easy to type.
This feels like an issue studied through a keyhole: You can do a study that makes underscores seem advantageous. And in a vacuum, a global with an uppercase name otherwise identical to a local with a lowercase name looks like a debacle waiting to happen. But, with a modern IDE, some combination of color, bold, and italics enables coders to easily distinguish among these seemingly inadvisable symbolic names. And if you want to find all uses of a name, that's easy.
While I find snake_case more readable when looking at the identifier alone, it has the downside that _ is mostly whitespace with the glyph at the bottom of the character cell, and so it visually groups more with punctuation like "." than with letters. Which wouldn't be so bad if "." wasn't so common in property / method call chains, so you end up with stuff like:
foo.bar_baz.blah()
being difficult to parse when quickly skimming through code. OTOH kebab-case solves this nicely because "-" is not in the same place as "." in the character cell, and being in the middle, groups more naturally with letters:
foo.bar-baz.blah()
Then again, maybe the established formatting conventions for member access are just suboptimal? Suppose that we put a space before every "."; then:
Also, when using a proportional font it gets worse, because underscores become wider (significantly wider than a normal space) and dots become narrower, suggesting the wrong grouping in syntax like `foo.bar_baz.blah()` (the words in "foo.bar" are closer together than in "bar_baz"), or just when having a snake_case_identifier in normal text ("a snake" is close together than "snake_case", etc.). This problem is less pronounced with kebab-case.
Underscores can also clash with hyperlink underlines, depending on the font. I've seen documentation with linked identifiers where that was confusing.
I admit there's personal preference and just quirks of vision involved, but I don't think I've ever had an issue distinguishing '_' and '.'. One thing you can do, which helps also with breaking up long chains of calls that would give you a really long line, is break it up with newlines, e.g.:
I believe that syntactic limitation to be a historical mistake that we keep doubling down on for no good reason. There's really no practical purpose to parse a-b as (a - b), as evidenced by popular style conventions for pretty much ever language with a binary minus operator.
I think it's more about reducing cognitive load. I wouldn't want "+" to be used for anything that isn't adding, for example. Having to differentiate a-b from a - b sounds tedious and error prone.
At most it's an error of 'a-b' not in scope. Unless you have dynamic scoping or somehow have a variable 'a-b' and also want to perform 'a - b'. I think the rule that binary operators must be separated by spaces is much easier to reason about then not having certain characters usable in identifiers.
There's precedent for this, though - 123.456 is lexed as one token in most languages, but foo.bar is three. It doesn't seem to be causing much issue in practice for readability because the context is sufficiently distinctive. Having / not having whitespace around the character would be even more distinctive, though, no?
FWIW I did write a fair bit of XPath (in XSLT context) and XQuery back in the day, which do allow kebab-case identifiers and use them for standard library names other than types, while also using minus as a binary operator. I don't recall ever consciously thinking about how to differentiate the two uses, not even when still learning the ropes coming from C++ and C#; it "just worked". Of course, this is anecdotal - it would be interesting to poll people with prior experience with kebab-case languages that have also been exposed to other styles regarding their overall preference and this specific ambiguity.
You'll have to put one extra Space before each "-" that is an operator. But you also won't have to reach for Shift every time you had to type "_", which is usually much more common. So I think even in this case you might end up typing code slightly faster on average!
COBOL has used the hyphen a.k.a. dash as the word separator in identifiers.
Then IBM PL/I (in 1964, when it was still named NPL) has replaced it with the underscore, to avoid the confusion with minus.
All the other programming languages that use underscores have taken this usage from PL/I.
Most LISP variants have continued to follow the COBOL practice, because they also have avoided the use of the minus sign as an operator.
Because ASCII includes only a single ambiguous HYPHEN/MINUS sign, as long as programs are restricted to be written in ASCII it is difficult to use the same sign both as an operator as a word separator. If U+2212 were used for the minus sign and U+002D for hyphen, with a typeface that differentiates them, the hyphen could replace the underscore, but that would not change anything for typing as they would still be two distinct keys.
For easier typing, I use a Dvorak variant, where -/_ is on the home row. Whoever uses the underscore more frequently than the minus may revert which of them is obtained with shift and which without shift.
Hyphen, which is the correct symbol for separating words in a compound word, is much shorter than the en dash, which is used in other contexts, e.g. as a figure dash.
The en dash has about the same length as the minus sign, so they cannot be distinguished visually, which is the purpose of using different characters for the word separator and for the mathematical operator.
I'm a fan of that idea; I would love to see other common operators (such as vertical pipe) reclaimed for expressing operations way more common in the past decade than bit twiddling (e.g. iterator/filter chaining, like in shell pipelines).
It complicates parsing significantly unless you avoid keywords altogether (i.e. all syntax is punctuation) or use some form of https://en.wikipedia.org/wiki/Stropping_(syntax) as early PLs did.
I think it's the most underrated "wart" of Lua. It's not strictly speaking a method call operator; it's a shorthand used to provide the LHS object (a table) as the first argument in a function call (where the function is looked up from that table).
So if you've implemented some form of inheritance (usually via metatables), you can trivially up/down-cast by using the dot notation and specifying the desired class/prototype for the method, and some instance/object as the first argument.
(Speaking of up/down-casting, classes, and instances in Lua is a bit awkward. I have a very quick & dirty "class.lua" file that I copy&paste between projects, I wish something like that was just a part of the stdlib.)
Why not both and neither? IMHO this is one of those things where people seem to congregate and advocate for one side religiously, but I don't see much value in that. Why can't the style simply imply how much scope and importance an identifier has? I've never liked naming dogma, but this is what I find to be natural:
trivialidentifier - local variables inside a function, usually < 3 words/abbrs
slightly_important_identifier - function names with limited scope
ImportantIdentifier - widely-used functions, class/struct names
More_Important_Identifier - classes/structs that are quite important
VERY_IMPORTANT_IDENTIFIER - global constants and (rarely) classes/structs
That seems less understandable to me. I think it's easier to grok if certain classes of things always use the same casing. So all functions would use snake_case, type names would use PascalCase, global constants use UPPER_CAMEL_CASE, etc.
"Importance" is subjective, and regardless, IMO not really an important measure of anything.
i think you need to do what the built-in functions/standard library of language X is doing; if it is camel case then do camel case in your own code - having your own code differ from the convention of the built-in functions/standard library is very confusing.
I'm more of a camelCase person than a snake_case, probably because I've been writing lots of JavaScript for the last 10 years. But, .... You could argue that camelCase is culturally insensitive given that plenty of languages (Japanese, Chinese, Korean, Hindi, Sanskrit, etc) have no concept of case.
Many modern computer languages (JavaScript, Rust, Swift, ...) allow non-ascii identifiers so if you pick camelCase, then someone writing Japanese, Chinese, Korean has no way to obey. That doesn't mean snake_case would be all that better in those languages though.
var 画面＿幅 = ...;
var 窓＿縦 = ...;
The point is, both camelCase and snake_case are a thing based around western languages.
I'm slightly conflicted about CamelCase. On the one hand it can be somewhat harder to read, on the other hand it does have a number of benefits:
- Typing "ABC" Ctrl+Space gives me code completion for AsynchronousByteChannel (and the like), whereas "abc" Ctrl+Space gives me code completion only for what strictly starts with "abc". I.e. uppercase means "words starting with that letter". Of course you could have something equivalent for non-CamelCase naming conventions, but for CamelCase it is a very natural fit.
- It provides the two variants lowerCamelCase and UpperCamelCase (often used for variable names vs. type names), whereas lower-kebab-case & Upper-Kebab-Case or lower_snake_case & Upper_Snake_Case seem more awkward in comparison (more keystrokes for the "upper" variant).
- When lowerCamelCase is used for function names, the case distinction often maps nicely to verb + noun (`createFooBar()`, `validateBazQuz()`).
- You still have underscore available to occasionally "index" a name (`transmogrifyFooBar()`, `transmogrifyFooBar_unchecked()`) unambiguously.
- The fact that CamelCase does not match normal English spelling has the advantage that it can't clash with it. CamelCase can stand both for hyphenated-compound-words as well as for open compound words (or just a phrase), whereas other naming conventions may look like the one although the words really stand for the other.
- Minor advantage: You can fit slightly more words into a line.
IDEA does something similar - you just type, and as long as the characters are found in the string in the order you typed them, it doesn't matter what's separating them, it will find a match.
So ABC would match AsynchronousByteChannel, and abc would match asynchronous_byte_channel. As would asyncbc or whatever else your brain comes up with.
I think IDEA actually splits a CamelCase identifier and expects your input to be a concatenation of prefixes of these parts, in the correct order, but parts may be omitted. Though the latest version goes further and also detects flipped characters, so maybe levenshtein distance on top of that.
The language I designed for Slint [https://github.com/slint-ui/slint] uses kebab-case, so it mandates spaces around the minus sign.
(If the lookup for `foo-bar` fails, it tries with `foo` and if that succeeds, the error message suggest the use of spaces)
The rule for kebab-case (regardless of whether or not it has a sigil) in Raku is:
- each part of the identifier must start with an alpha character
- cannot end with -
So, "foo-bar" would be legal, "foo-" would not, "foo-4" would be considered "foo" - 4. If you want to substract two sigilless identifiers, you *must* have whitespace between them. So "foo - bar" instead of "foo-bar".
265 comments
[ 4.7 ms ] story [ 245 ms ] threadI have found that most of the time you can just automatically switch between the two cases, too. So maybe it’s moot.
Cool trick about mapping shift keys with Karabiner-Elements. I do that with my caps lock to create a "hyper" key: tapping it brings up Alfred, using it in a chord is "hyper", and long pressing caps lock maintains its default behavior.
But '_' might be difficult to hit on non-US keyboards though.
Upper case is majuscule.
Lower case is miniscule.
Mixed case is ridicule.
https://en.wikipedia.org/wiki/Letter_case#Terminology
more seriously, it is the unfortunate fact that a lot of systems interpret named-thing and named minus thing. many people don't have the option of using kebab-case. it isn't a good style because it is often impossible to use. which is unfortunate because it is more ergonomic.
Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen").
Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
I know this for a fact since I've studied their grammars.
Infix notation and - are really the reasons why nobody does this, some people like to use spacing to indicate precedence too (writing code such as "a - 1*g") so it would break some workflows and realistically having a language which is whitespace agnostic except for identifiers AND the minus operator just seems too irregular for people to commit to it.
[0] https://elm-lang.org/news/0.9
First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language. This is very useful because then you can have identifiers like "a+b", or even identifiers like "a+[b+c-d]" etc... As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that, well now you're not allowed to condense arithmetic operations. This may or may not be a problem, depending on the programming language designer. When you said:
> I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
I'm guessing your opinion is that you're ok with this trade-off. Fact of the matter is that this a very fringe syntax for any programming language to have. As an Agda programmer, I like it, and it is useful, but I'm not convinced something like this would find mass appeal.
The last option I'm aware is to have semantic differentiation. When you find a statement like "c = a-b" you need to ask two things. One, are there identifiers "a", "b" and "a-b". If "a-b" exist and "a" or "b" doesn't exist, you're all set. If all three exist, second question is, are "a" and "b" subtractible? If the answer is yes then programming language designer can choose to prioritize "a - b" over identifier "a-b". Alternatively, you can always choose to prioritize identifier "a-b" as long as it exists. I'm personally not aware of any language that implements something like this, however I have implemented toy languages that go through this, it's pretty easy. It's a matter of making the decision to introduce this type of complexity into your language.
All in all, although I love kebab case, in order to have it in your language you need to make pretty significant trade-offs. Given this, I'm not surprised any mainstream non-lisp-like language doesn't have it.
This is a gross error. In your sense, Lisp does not even have operators, only identifiers. The reason there is no confusion between "(- a b)" and "(-ab)" is the spacing that separates the three identifiers in the first case.[1]
Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does".
[1] However, Lisp does have a potential problem with identifiers that begin with a hyphen, due to the need to support literal numeric values like -3. Thus the Common Lisp decrement function is named "1-" despite not returning the value (1 - operand).
I assume you're talking about GP's third paragraph here. Assuming that's true, I think you've misinterpreted it: GP was talking about using infix operator notation, which is most certainly not what Lisp does.
Lisp will treat (a - b) as 5 tokens, just the same way it will treat (- a b) as 5 tokens. Infix operators are completely unrelated to this problem. What lisp is doing is determining tokens by reference to spacing (the parentheses don't need to be spaced; I believe they are reader macros but in any event they are special-cased) and then acting on the tokens. What C is doing is not that; the concept is that you eliminate all spacing before you decide what the tokens are.
So in C, there is no such thing as "a - b", only "a-b", and that's why "a-b" cannot be used as an identifier.
If you want to write your lisp in infix notation, you can, but it will remain true that (a - b) is a list with 3 elements and (a-b) is a list with 1 element, which is what matters here.
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with.
> Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language.
is kinda not good, Lisp allows "-" in names the same reason as Agda: it tokenize by spaces (correct me if I'm wrong). This may seem as a gross error for one, and an only implied who cares error which is even true if taken word-by-word, for an other.
You're spot on about the quirky syntax, but I don't think it's as serious a trade-off or addition in complexity (or even a change), given that:
- (IIRC) many style-guides/formatters already enforce spaces between binary operators and their operands (but especially identifiers) and in my super-subjectively-opinionated opinion you should already be doing that even without a formatter
- I don't feel particularly strongly one way or another about any other special characters like "+", so really in this case I'm only considering the dash
- Requiring the dash be between alpha/alphanumerics makes it play nice with unary operators
- The language would be terrible for code-golfing, but that's a relatively niche application I'd definitely consider worth spurning
I would say the trade off is variable names like “a+b” themselves. I fail to see any reason why would I want something like that, like even in Math where the grammar is very hand-wavy to accommodate human parsing you would be insane to write that (though to be fair, math does have their own share of problem with identifiers, enumerating all the letters in different alphabets is not a sustainable solution)
But I think OP meant programming languages, not styling or markup.
With a good font it would basically look similar to what a good IDE with syntax highlighting already does (different color for operators).
This might be a bit old school but I prefer things limited to plain ASCII. There's only so many keys on a keyboard and want to be able to touch type everything without thinking or looking at a special emoji bar.
I'd suggest that it's feasible if we lived our entire developer lives inside a monoculture that adopted it, but that just ain't reality.
This all adds up to "why I do not kebab my identifiers".
You can't have infix minus and kebab case without something to differentiate between the two.
Lisp chooses to remove infix minus. Other than old-school BASIC, I don't remember anything else which uses tokens for variables.
Infix has nothing to do with it. - refers to the subtraction function regardless of whether it is placed in prefix or infix position. Infix will trigger a type error, not a syntactic error — it will tell you that e.g. it cannot call a fixnum. Lisp quite ordinarily requires function names to be separated from their arguments by spaces, which is just a special case of the rule that atoms need to be separated by spaces. That’s all.
Thus + serves more than one purpose: function or variable and both may be different values.
Thus the position actually matters.
What we have below the Lisp syntax are s-expressions: nested lists of symbols and other objects. In s-expressions, symbols need to be separated by whitespace, parentheses or possibly by some special character type (-> terminating character). Characters like +, -, /, *, _, ... are valid characters for any symbols.
Thus Lisp does not require functions to be separated by characters but symbols. That's a part of the reader mechanism for reading s-expressions (-> symbolic expression).
Goldman Sachs' Slang language allowed spaces in tokens which was actually much better but I guess your grammar has to support that from the ground up.
This may be why I tend to gravitate towards languages like Elixir and Ruby, who prefer snake_case, and away from languages like Go, which use camelCase.
I tried to convince my co-workers toTransitionFromCamelCase to the world_of_easy_reading_snake_case, but alas, the codebase alreadyUsingCamelCase won.
Maybe it's the idea that "shorter == better", or whatever, but if I could choose, I would use snake_case_everywhere man.
__privateish_variable
Etc, in the land of Python
The double underscore for __super_private_function doesn't make much sense to me though. I can't see a reason why this shouldn't just be a single underscore, especially when __double_underscore__ signals very important python internals
> Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped.
See https://docs.python.org/3/tutorial/classes.html#private-vari...
That said, data in this study is interesting for being data and a replication. I don't know that I've given much thought to liking one style over the other in a long time, neat to see the impact it can have.
Directly to your last point, I do greatly prefer single word names, if they can be used. So, `candidates` over `candidateList` or `candidate_list`.
I wonder if a lot of people rebind the underscore character to a more convenient key?
But having to press shift for a capitalised word is not a pain. OK, sounds about right.
Another consideration: whether the program you're typing in will stop at underscores or hyphens when using Ctrl + Shift + Left/Right Arrow when highlighting. If I want to highlight `this_variable_with_a_long_name` without using the mouse, it's going to be a pain if I have to hit the left arrow key six times instead of once. (Frustratingly, it varies from editor to editor.)
As far as keyboard navigation around partial or whole words, I find it really helpful to have separate keybindings. For me (on a Mac so keyboard layouts matter), opt+left/right moves a “whole word” (as in to the nearest non-word character) and ctrl+left/right moves to the nearest internal word boundary (where boundary is mostly arbitrary; in bouncyCase it moves to the nearest non contiguous case change, in any-punctuated_case it moves to the nearest punctuation).
Agree it’s frustrating how much this varies by editor, but being able to configure the behavior is one of my first checks when deciding if I’ll use the editor at all.
Many years ago, I was programming in COBOL, where kebab-case is the norm. For a while there I was programming in both "C" AND in COBOL. That was a nightmare, I invariably used the wrong syntax for my variable-names, as both languages used incompatible syntax for those variable-names.
But yeah kebab-case-might-be-easier than camelCaseToRead in the long run.
and it’s also quite far from the home row on the keyboard.
I'm not going to adopt a coding style that requires me to reach that far repeatedly for every name.
Also.dot.case.wins.all.
If you're really perverse you can do the same for 9/( and 0/), because most programmers type parens way more often than the type 9 or 0.
Code is written once but read many times. Better to optimize for reading than writing.
Maybe when defining a new variable/class/etc. the first time, then IDE autocomplete fills it in the next.
I create bindings using Karabiner (Mac) for all symbols so that I don’t have to press Shift or leave the home position.
Underscore is “s comma”.
For me OriginalAmount or AdjustmentFees are just one word each.
Snake is my preferred. The Python/Rust use of snake case and Pascal case for their respective purposes is my favorite.
Frameworks, IDEs, and linters all follow the PSR-2: https://www.php-fig.org/psr/psr-2/ .
It is indeed common for new developers to not know or care about it, but most professional shops I've been to adhere to it unless they're working on very legacy code.
Thanks for that.
Thank goodness for PyCharm auto-complete. Typing every variable name fully manually in snake_case 24/7 everyday was begging for me to develop RSI.
Honestly though I am that kind of monster
The obvious solution would appear to be to use better keyboards, but I don't even see anyone suggesting that.
But note that the lisp identifier style, words-separated-by-hyphens, is better than using underscores despite being less legible. It's purely a matter of how easy it is to type the separator. ("Standard" languages don't allow hyphens in identifier names because they want to allow subtraction without requiring a space between the subtraction operator - and the two operands. In Lisp, spacing around an operator, including the subtraction operator, is required. You could go a long way in a C-like language by just requiring spacing around operators and immediately being able to allow hyphens in identifiers.)
Shift key is a problem for all the shifted only chars. Their major problem is appearance: a single underscore '_' vs underscores '__' . Concatenated glyphs are hard to discern due to only distinguisher being width.
We have various natural languages to tell us: https://en.wikipedia.org/wiki/Syntactic_ambiguity
How about Unicode "Thin Space" 0x2009 for a legal identifier character? (HN isn't letting me put the Thin Space in there.)
How about Unicode "Middle Dot" 0x00B7 for a legal identifier·character?
Best if you aren't in a fixed with editor for those.
I used middle dot in an experimental language which was Unicode heavy so already didn't like fixed width fonts. It parses trivially and reads well.
I haven't tried the thin space in earnest, but the example code I typed up looked reasonable.
Underscores can also clash with hyperlink underlines, depending on the font. I've seen documentation with linked identifiers where that was confusing.
So I don't really think people would have a problem with kebab case after getting used to it for a couple of minutes.
FWIW I did write a fair bit of XPath (in XSLT context) and XQuery back in the day, which do allow kebab-case identifiers and use them for standard library names other than types, while also using minus as a binary operator. I don't recall ever consciously thinking about how to differentiate the two uses, not even when still learning the ropes coming from C++ and C#; it "just worked". Of course, this is anecdotal - it would be interesting to poll people with prior experience with kebab-case languages that have also been exposed to other styles regarding their overall preference and this specific ambiguity.
Then IBM PL/I (in 1964, when it was still named NPL) has replaced it with the underscore, to avoid the confusion with minus.
All the other programming languages that use underscores have taken this usage from PL/I.
Most LISP variants have continued to follow the COBOL practice, because they also have avoided the use of the minus sign as an operator.
Because ASCII includes only a single ambiguous HYPHEN/MINUS sign, as long as programs are restricted to be written in ASCII it is difficult to use the same sign both as an operator as a word separator. If U+2212 were used for the minus sign and U+002D for hyphen, with a typeface that differentiates them, the hyphen could replace the underscore, but that would not change anything for typing as they would still be two distinct keys.
For easier typing, I use a Dvorak variant, where -/_ is on the home row. Whoever uses the underscore more frequently than the minus may revert which of them is obtained with shift and which without shift.
Hyphen, which is the correct symbol for separating words in a compound word, is much shorter than the en dash, which is used in other contexts, e.g. as a figure dash.
The en dash has about the same length as the minus sign, so they cannot be distinguished visually, which is the purpose of using different characters for the word separator and for the mathematical operator.
So if you've implemented some form of inheritance (usually via metatables), you can trivially up/down-cast by using the dot notation and specifying the desired class/prototype for the method, and some instance/object as the first argument.
(Speaking of up/down-casting, classes, and instances in Lua is a bit awkward. I have a very quick & dirty "class.lua" file that I copy&paste between projects, I wish something like that was just a part of the stdlib.)
Yes, I do like kebab-case. Common Lisp!
"Importance" is subjective, and regardless, IMO not really an important measure of anything.
Many modern computer languages (JavaScript, Rust, Swift, ...) allow non-ascii identifiers so if you pick camelCase, then someone writing Japanese, Chinese, Korean has no way to obey. That doesn't mean snake_case would be all that better in those languages though.
The point is, both camelCase and snake_case are a thing based around western languages.- Typing "ABC" Ctrl+Space gives me code completion for AsynchronousByteChannel (and the like), whereas "abc" Ctrl+Space gives me code completion only for what strictly starts with "abc". I.e. uppercase means "words starting with that letter". Of course you could have something equivalent for non-CamelCase naming conventions, but for CamelCase it is a very natural fit.
- It provides the two variants lowerCamelCase and UpperCamelCase (often used for variable names vs. type names), whereas lower-kebab-case & Upper-Kebab-Case or lower_snake_case & Upper_Snake_Case seem more awkward in comparison (more keystrokes for the "upper" variant).
- When lowerCamelCase is used for function names, the case distinction often maps nicely to verb + noun (`createFooBar()`, `validateBazQuz()`).
- You still have underscore available to occasionally "index" a name (`transmogrifyFooBar()`, `transmogrifyFooBar_unchecked()`) unambiguously.
- The fact that CamelCase does not match normal English spelling has the advantage that it can't clash with it. CamelCase can stand both for hyphenated-compound-words as well as for open compound words (or just a phrase), whereas other naming conventions may look like the one although the words really stand for the other.
- Minor advantage: You can fit slightly more words into a line.
Apart from that, I'm pro-kebab-case.
that's clever. I suspect you could add editor logic to do that with underscores too.
So ABC would match AsynchronousByteChannel, and abc would match asynchronous_byte_channel. As would asyncbc or whatever else your brain comes up with.
It's quite nice.
Since such features often cross environments I wouldn’t be surprised if other editors/IDEs had similar stuff.
- each part of the identifier must start with an alpha character
- cannot end with -
So, "foo-bar" would be legal, "foo-" would not, "foo-4" would be considered "foo" - 4. If you want to substract two sigilless identifiers, you *must* have whitespace between them. So "foo - bar" instead of "foo-bar".