Hacker News Reader

Comment by inDigiNeous | Hacker News Reader

Good to see some scientific studies on the easier_readability_of_snake_case, versusComparedToCamelCaseBouncingUpAndDown.

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.

View on HN

I am pro-snake myself, but those that use double underscores, especially in a meaningful way, are drilling holes in our boat.

What is a double underscore?

    hello__world?

Yep, or "dunder" as it's often called in the python world.

__special_functions__

__privateish_variable

Etc, in the land of Python

I wish Python enforced private attributes. I once worked in a codebase where this was roughly true:

  _usually_private_but_ok_to_access_if_you_are_knowledgeable
  __private_unless_you_need_an_escape_hatch
  ___absolutely_private_except_for_a_few_times

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.

See https://docs.python.org/3/tutorial/classes.html#private-vari...

I do prefer snakecase visually but having to press shift for the underscore is a pain and it’s also quite far from the home row on the keyboard.

I wonder if a lot of people rebind the underscore character to a more convenient key?

but having to press shift for the underscore is a pain

But having to press shift for a capitalised word is not a pain. OK, sounds about right.

Ha! You got me there.

For me it is easier/faster to type uppercase letters than an underscore. But, I have small hands.

Same. I'm noticeably faster with camelCase.

That's why kebab-case-is-best.

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

This might be configurable: vim and emacs, at least, let you define which characters are part of a word.

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?

Sounds like job security!

  x-y = ‘a string or something’
  # 
  # bunch of lines of code here
  #
  x = 5
  y = 2
  assert x-y == 3

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.

Well, this-case-has-the-problem-of-mixing-with-the-letters-more-easily. When you type snake_case it is clearly not in the line of the letters.

But yeah kebab-case-might-be-easier than camelCaseToRead in the long run.

I've bound underscore to a top-level key in my default keymap. It's made a big difference to me!

The position of the -/_ key is a bit awkward relative to the right-hand shift key in the US layout.

You skipped the important half of the sentence:

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.

kebab-case-would-be-the-best-but-it-is-unfortunately-not-supported-by-most-languages

Indeed. I wouldn't have a strong preference between snake_case and camelCase, but I use snake_case for new code because it's closer to kebab-case.

This makes me feel uncomfortable

You and me both, brother.

Also.dot.case.wins.all.

And—long—kebab—case—isn't—well—supported—by—most—keyboards.

Works great on Macs, and the default layout makes it an easier reach than underscores!

Those are "em" dashes, not hyphens. Shift+Option+- is harder than Shift+-.

Obviously you should swap the bindings for _ and - (so you press shift for dash instead of the other way around).

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.

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

I bound _ to capslock + u. It is very convenient for both hands.

> I do prefer snakecase visually but having to press shift for the underscore is a pain

Code is written once but read many times. Better to optimize for reading than writing.

My dream is a programmer's keyboard where part of the spacebar is underscore. Also add A-F to the 10key numerical keypad.

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 thought about this, but realised that I don't spend that much time typing when coding.

Maybe when defining a new variable/class/etc. the first time, then IDE autocomplete fills it in the next.

> I wonder if a lot of people rebind the underscore character to a more convenient key?

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

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

Definitely shorter is better especially when the names are incredibly long. Also helps in narrow word wrapped screens.

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.

Reply on news.ycombinator.com