Comment by skohan
4 years ago
I'd argue it's at most a tiny bit harder to read, and a lot easier to type. On balance I'd rather avoid making a pinky key one of the keys I have to use the most.
4 years ago
I'd argue it's at most a tiny bit harder to read, and a lot easier to type. On balance I'd rather avoid making a pinky key one of the keys I have to use the most.
"On balance I'd rather avoid making a pinky key one of the keys I have to use the most."
And you use something else than your pinky finger for the shift key specifically when typing capitalized letters for camelCase?
At least it's where they sit naturally on the keyboard. And the shift key is wider specifically so you don't have to be accurate with your pinky when you're pressing it. The underscore is one of the least ergonomic keys there is. And you need both pinkies to do it
I might be misunderstanding. On all layouts I'm familiar with the underscore key is directly next to one of the shift keys, or left of backspace. Neither layout requires the Vulcan death grip. Shift should always be under your pinky fingers to avoid contortions.
1 reply →
Having used a lot of all the formats, it's argue it's a lot easier to read an a tiny bit harder to type. For typing it's basically just an extra `-` because unless your alternative is nocase.
For reading, CamelCase has 2 significant ambiguity issues: similarity between I and l, and what do you do with acronyms. Acronyms wouldn't actually be a problem if everybody just wrote them would in snake_case (i.e. only capitalize the first letter), but they don't and so it's anyone's guess whether you're going to get "Id" or "ID".
There's also a minor issue where if you're on a case-insensitive file system it can be a little difficult to change casing, but adding/removing underscores is easy.
Adding an underscore everywhere is horrible! The spacebar is huge, and gets your thumbs basically to itself because space will be one of, if not the most commonly typed key. To replace that with one of the least ergonomic keys makes no sense.
And if CamelCase is so hard to read, why is it the norm for "high level languages"? Shouldn't those be optimized for ease of use?
> And if CamelCase is so hard to read, why is it the norm for "high level languages"
That's over-selling it a bit. It's more common, but not dramatically so. Outside of class names, CamelCase isn't the norm for Python, PHP, CSS, HTML. It's also not the norm for shell scripting, but shell scripting has horrible readability for other reasons.
I believe CamelCase is more common for languages like Go, C#, and Java because they grew up in large organizations where having god objects/classes with 400 methods is kinda normal and having aMethodWithAReallyLongName is pretty common. One of the advantages of CamelCase is that it does shorten really long names.