Comment by frenchyatwork
4 years ago
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.