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.