23

Depending on your interpretation this may or may not be a rhetorical question, but it really baffles me. What sense does this convention make? I understand naming conventions don't necessarily have to have a rhyme or reason behind them, but why deviate from the already popular camelCase? Is there a rhyme and reason behind lower_case_with_underscores that I'm somehow missing? (and yes, I have read PEP 8 in its entirety, and yes, I do understand that it's merely a proposal, a guide, etc.)

I suppose my real question would be this: I'm writing a Python library. In fact, with any luck, it may be a rather large library, relative to my other projects. I already try to adhere to PEP 8 as much as possible, and so far I've even maintained lower_case_with_underscores as PEP 8 instructs for function and method names. But it bugs me that I have to remember to use camelCase for Twisted, camelCase for logging, and just about everything else. What naming convention should I use, and why?

It would probably amaze people that I care this much about naming, enough to write a lengthy question about it, and it amazes me, too. Perhaps I have a little OCD when it comes to these things. I don't have much of a "personal opinion" about it as much as I have a tendency to just go for whatever is used the most, which in this case, would be camelCase - but it annoys me even further to find out that I'm probably breaking some eternal laws about explicit vs implicit and the zen of python written in stone or something.

dav
  • 1,211
  • 1
  • 13
  • 19
  • 7
    "but why deviate from the already popular camelCase?" I believe lower_case_with_underscores is much older than camelCase. Also, I personally loathe camelCase of any kind of MixedCase with a burning passion. Use whichever convention you prefer. – Chris Lutz Nov 16 '09 at 04:57
  • 2
    Use Systems Hungarian. :P But seriously, it wouldn't amaze people at all - coding style conventions are as much a religious war as any other aspect of programming. You'll find plenty of questions on SO devoted to where to put curly braces, or the zen of whitespace. – Xiaofu Nov 16 '09 at 05:04
  • 1
    How is hungarian supposed to work with ducktyping? :p – John La Rooy Nov 16 '09 at 05:05
  • 2
    It's not, I thought my sarcasm was fairly obvious. :) – Xiaofu Nov 16 '09 at 05:12
  • 1
    In any case, lower_case_with_underscores is a clumsy designation. I believe "snake case" is the correct term for this, FWIW. – mazelife Nov 16 '09 at 05:16
  • @mazelife - Incidentally, I think the exact same thing about camelCase. – Chris Lutz Nov 16 '09 at 05:21
  • 1
    It's unfortunate that CamelCase (or camelCase) won out over the superior StudlyCaps (or studlyCaps) for naming contention naming rights. – Corey Porter Nov 16 '09 at 05:26
  • I hear you. The underscore is one more key press and one more character taken up! – Humphrey Bogart Feb 23 '10 at 19:25
  • 1
    This is clearly old, I come from other languages and I'm genuinely mystified by why snake case would ever be the primary style choice -- camelCase contains fewer characters and requires fewer keystrokes by definition. I can see using snake case for constant names that are otherwise in all caps, like SOME_CONSTANT_NAME because there's otherwise no way to delineate words, but for regular variables/methods it just seems laborious to add underscores everywhere, and in my opinion it feels less readable because variable names look less separated from spaces around them. – Benjamin Robinson Sep 06 '18 at 13:59

10 Answers10

53

camelCase and/or CamelCase (and that's a debate in its own right;-) may be overwhelmingly most popular for the kind of environments you are most familiar with, but that hardly makes them universal -- or have you never heard of the obscure language called C++, with its std::find_first_of and std::replace_copy_if algorithms and so on?!

So there's no "deviation", as you state, in PEP 8 -- simply a choice towards the C++-standard conventions against the ones more popular in, say, Java or C#.

As for what you should do for your own code, just pick a convention and stick with it -- consistency's more important than other considerations. My employer uses a CamelCase convention across all languages for all internal sources (though not necessarily when it comes to exposing public APIs, which is a separate issue), I personally detest it (I wish I could destroy every reliance on case sensitivity across the programming universe!-), but I stick to it, and actually help enforce it (in code reviews), because uniformity is important.

I guess you'll understand why relying on case sensitivity is a horrible idea only if and when you have to rely on a screen reader to read code out to you -- most screen readers do a horrible job at pinpointing case issues, and there's no really good way, no strong or easy convention to convert case differences to easy auditory clues (while translating underscores to "clicks", in a good configurable screen reader, makes it a breeze). For people without any visual impairments whatsoever, which is no doubt 90% or more, you don't need to care (unless you want to be inclusive and help people who don't share your gift of perfect vision... naah, who cares about those guys, right?!).

But, consistency is still important, and helps _every_body.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • 15
    Wow! I never considered naming conventions as an accessibility issue before. +1 just for opening my eyes to this. – gotgenes Nov 16 '09 at 05:38
  • 4
    @gotgenes, tx -- and around the same time, somebody else anonymously -1'd it... I guess some people just don't **like** to be reminded that not everybody has perfect eyesight, so, mentioning that little detail will also attract down-votes (under the cover and protection of anonymity, of course, by anonymous cowards happy to be such;-). But, even making **one** good person like you (one who _cares_ and just wasn't aware of the issue) now aware and likely to consider this in the future, is well worth whatever downvotes come my way! – Alex Martelli Nov 16 '09 at 05:49
  • 2
    I second that, I had never thought about the accessibility issue before. Thanks for enlightening me (us). – dav Nov 16 '09 at 16:03
  • 2
    Apparently, an [eye tracking study was conducted](http://bit.ly/1byZSic) on the subject of camelCase vs under_score. "Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style ... with experience or training, the performance difference between styles is reduced." Accessibility was not taken into account, though. – blablatros Jul 20 '13 at 13:24
  • @blablatros - Thanks for sharing the study. Good hard data is better than opinions any time! – Shahstewart Apr 07 '22 at 16:04
20

LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis. .

smcameron
  • 1,307
  • 8
  • 8
16

I've heard it stated in other contexts that words_with_underscores are easier to separate for non-native English readers than are wordByCamelCase. Visually it requires less effort to parse the separate, foreign words.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Easier visual separation *is* the reason explicitly mentioned for the programming language Eiffel. They also have this underscore_separator_standard. It probably also helps for native English readers :-) – Reinout van Rees Nov 16 '09 at 09:47
  • It is easier to read in any case. Proof of consept: TheQuickBrownFoxJumpsOverTheLazyDog vs the_quick_brown_fox_jumps_over_the_lazy_dog. The last one is possible to read at normal high speed, while the brain goes into super slow concentation mode when trying to decode the first alternative. – hlovdal Dec 04 '10 at 19:45
  • 4
    Hmm - I think I parsed the first one faster than the latter. I'm a native English speaker, though. – Matthew Cornell Sep 10 '12 at 14:35
  • 1
    @hlovdal the CamelCaseVErsion is way easier to read for me. It is slower to read than proper text. However the underscore version is much harder to read for me. The shape of the words is broken and the spaces are filled up. "the-quick-brown-fox-jumps-over-the-lazy-dog" is easy (but breathless!) to read. I think there are two things to take away: (a) don't generalise based on your own perception, (b) do not use long variable names. – gschenk Feb 01 '21 at 14:16
7

One reason could be historically, many computers did not have mixed case capabilities. In the days of COBOL, programs were all upper case. In the early 80's many 'personal computers' only came with upper case fonts. For example, you could get a lower case extender card for the Apple II+. When programs began allowing for mixed case, camel case was not popular. Many programs took what used to be in all caps, and just converted to lower case. Through the 80's various languages attributed meaning to case, and in the 90's Java popularized the camelCase syntax. Languages which have an older history, or are tied more closely to unix system programming tend to avoid making semantic use of mixed case.

brianegge
  • 29,240
  • 13
  • 74
  • 99
  • cobol code looks like magic. i once saw a colleagues code. it was so elegant. they've had 70 years to fine tune it though. – mjs Jun 01 '20 at 22:46
5

The lower case with underscores convention goes all the way back to unix apis. Their entire syscall are in this convention.

Amirshk
  • 8,170
  • 2
  • 35
  • 64
  • 4
    It goes back further - Lisp allows hyphens in identifiers, and multiple word function names in Lisps are separated with hyphens in the same way that modern languages use underscores. I'd say that this is at least the same concept (using a substitute character since whitespace isn't allowed). – Chris Lutz Nov 16 '09 at 05:01
3

It is just a convention, but a useful one if you work with a lot of abbreviations.

How did you write EmailConfig (or was it EMailConfig)? HTTPRequest? email_config and http_request are then much clearer convention.

Peter Smit
  • 27,696
  • 33
  • 111
  • 170
2

Use the naming convention that your shop uses.

If they agree that the existing convention is dorky (or they don't have a standard), and don't mind a little work cleaning up all of the code to a new and improved (more standard) convention, then you can do that.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
2

Whatever you do, I think it is important that you are consistent. I have seen a couple of style guides (for example Google Python Style Guide), that tell you to use underscores.

I personally think, using lowercase letters with underscores makes the code easier to read.

You use camelCasing? I don't mind! There is always Glasses Mode. :)

cschol
  • 12,799
  • 11
  • 66
  • 80
1

Was it Meyers who came up with aLongAndTotallyUnreadableMethodeName vs an_even_longer_but_perfectly_readable_method_name comparison?

If you are already used to one, then your favorite convention will look more natural. But new programmers may prefer underscores (sample size N = me, in the year 2001).

I think some languages use camelCase because their API can be really horrible. You need the extra space so the code can fit in the IDE without wrapping.

For example:

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset())
wisty
  • 6,981
  • 1
  • 30
  • 29
  • Not sure if the example code is an argument against snake case since it doesn't jive well with the Law of Demeter. – Juliet Nov 16 '09 at 21:06
0

Feel free to do whatever suits you best, but consider using one of the popular conventions. It makes it easier for other developers to get up to speed with your code.

Remember that over the life of the project, more time is spent reading the code than it takes to write it.

John La Rooy
  • 295,403
  • 53
  • 369
  • 502