CamelCase vs. underscore_case

If the STL could be designed again, I wish it would have chosen CamelCase instead of underscore_case.

Since STL uses underscore_case, we're stuck with two unattractive stylistic choices:
  • Use underscore_case in our programs, and suffer its drawbacks.
  • Use CamelCase in our programs, and suffer the inconsistency with STL.
A couple years ago, I tried to get over my distaste for underscore_case, and wrote a small library of 6,500 lines in that style. I thought I'd convert. Instead, I now want to burn underscore_case with fire.

Which person in their right mind decides to sacrifice 26 out of 63 perfectly useful symbols, and pretend they don't exist? Did this person spill Coke on the Shift key of their keyboard, or something?

If you allow uppercase – like normal people who aren't shooting themselves in the foot – you can do this:
    struct Thing { int thing; };
    Thing thing;
How do you do this with underscore_case? You don't. Both things have to be named differently.

You're constantly tripping over yourself due to the lack of orthogonality. With no uppercase, there is a strict reduction in expressiveness: it brings no benefit, and reduces flexibility. It requires using longer and uglier names, and you can't express in a name whether it's a type, or a method, or a member.

But this study...


Someone replied with this eye-tracking study, which claimed finding that CamelCase identifiers take 20% longer to read. Yet the paper disclaims: "One main difference is that subjects were trained mainly in the underscore style and were all programmers."

They even summarize another study, which used more participants trained in CamelCase: "Their findings show that camel-cased identifiers lead to higher accuracy among all subjects, and those trained in the camel-case style, were able to recognize camel-cased identifiers faster."

What both studies appear to confirm is that people do better in the style they are used to. No way. :)

For me, underscore_case requires effort to use. I can't easily tell where an identifier begins and ends, because underscores look like punctuation. But I understand this is due to training. I could get used to underscore_case, and use it equally well, if I thought it was the preferable style.

Type and variable names in underscore_case are not orthogonal. Given that we can get used to either style, it seems peculiar to make the less powerful choice knowingly.

Comments

John Hayes said…
agreed - cest la vie for C++ standards tho buddy.

(HEY! YOU'RE ONLY ALLOWED TO "POST" DATA USING HTTP WHEN YOU INCLUDE A BODY!!)
Arne Mertz said…
I agree that underscore_case is not pretty. Otoh I somewhat got used to see easily distinguishable calls to the standard library and boost, so I think it's not that bad.
However I disagree with your class A example: single character class names are worse than underscore_case or any other case convention. Same goes for variable names (except loop variables).
denis bider said…
Arne - thanks for your comment.

The example is trivial on purpose. I wouldn't use single-character type name in working code. However, I routinely use Thing as a type, and thing as an instance of that type.

A lesser version of the problem exists with members. In underscore_case, if thing is a type, I will be tempted to use m_thing as a member somewhere. But then, if I have to capture a reference to that member, I have to do something like this:

thing const& thng { x.m_thing };

With CamelCase, type and variable names are orthogonal:

Thing const& thing { x.m_thing };

Popular posts from this blog

When monospace fonts aren't: The Unicode character width nightmare

"Unreachable" beauty standards

Is the internet ready for DMARC with p=reject?