For what reason do we have the lower_case_with_und

问题:

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.

回答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.

回答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.

回答3:

LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis. .

回答4:

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.

回答5:

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

回答6:

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.

回答7:

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

回答8:

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.

回答9:

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

回答10:

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.