For what reason do we have the lower_case_with_und

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.