← Back to context

Comment by skohan

4 years ago

What's wrong with camelCase? It's easier to type than snake

There's a tendency away from snake_case and towards kebab-case in things you interact with via CLI. Even moreso towards nocase.

Programs like Powershell eschew ease of use in CLI for readability in scripts.

  • > Even moreso towards nocase.

    Nocase (did I break a rule by writing it that way?) seems great when you're enmeshed in the domain and you can see the implicit separators, but then someone looks at your naming from the outside and you're guaranteed to have an 'expertsexchange' in there somewhere.

  • Snake_case is problematic for including filenames in TeX also. This is a big no for me, even if I find it more readable than the other.

camelCase is objectively harder to read than snake_case or kebab-case, though familiarity can mitigate that.

  • 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?

      3 replies →

    • 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.

      3 replies →