Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

PEP8 recommends using

lowercase, with words separated by underscores as necessary to improve readability

for variable and function names. I've seen this interpreted as lower_case_with_underscores by most people, although in practice and in Python's native methods it seems like lowercasewithoutunderscores is more popular.

It seems like following PEP8 strictly would be awkward since it seems to suggest mixing both lower_case_with_underscores and lowercasewithoutunderscores, which would be inconsistent.

What is your interpretation of PEP8's variable names, and what do you actually use in practice?

(Personally, I like lowerCamelCase as a compromise between readability and ease of typing.)

share|improve this question

closed as primarily opinion-based by durron597, MichaelT, GlenH7, Snowman, Dan Pichelman Aug 11 at 17:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers 3

up vote 5 down vote accepted

PEPs should be read with a grain of salt. It is what the Python devs would like to do if they could clean the slate, though it was written much later than much of the actual language. For reasons of backwards compatibility, it hasn't been retroactively applied to everything, and many modules will inherit the naming style from their core dependencies rather than following the guidelines (which is actually intended, and part of the guidelines).

share|improve this answer

For local variables, underscored_lowercase works well, as does InitialCapitalCamelCase for class names. This is all per PEP8.

C/Java stroke a good balance, imho, by using initialLowerCamelCase for functions which is hard to mix up with either local vars or classes. While Python's stdlib uses a different convention, many 3rd party Python libs use this convention. This does not contradict PEP8 which 'gives coding conventions for the Python code comprising the standard library in the main Python distribution' and does not try to regulate other code.

Also, as they say, consistency matters. It's not that important which convention you pick, it's important to stick with it throughout. The point of convention is to remove a piece of mental effort regarding naming; inconsistency destroys all of its benefits.

share|improve this answer

Seems like they were in a different camp before, and somewhere along switched for readability reasons.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

I appreciate a language which dares to follow the underscore minority, even more so, change their existing convention for the best!

CamelCasing exists mainly for historic reasons.

  • "It was only in the late 1960s that the widespread adoption of the ASCII character set made both lower case and the underscore character "_" universally available."
  • Early compilers severely restricted the length of identifiers (e.g., to 8 or 14 letters)
  • Finally, the small size of computer displays available in the 1970s encouraged the use of short identifiers.

On a scientific note, camelCasing is proven to read 13.5% slower than using underscores.

Ofcourse, it is still important to follow convention as is also clear from these Programmers.SE answers on the subject.

share|improve this answer
Interestingly, the paper in the "scientific note" actually concludes that camelCasing is better (more accurate recognition), and faster after you have trained to use it. –  squirrel Feb 26 '11 at 11:45
@squirrel: I discuss the reason why I believe accuracy isn't important in the "discussion" part of my blog. By correctness they refer to being able to distinguish small differences like startTime vs startMime. You have autocompletion anyhow, and errors are underlined. The main concern (at least for us underscore junkies) is that it reads slower. That's where you lose time. I don't find myself writing errors due to similar var names, or it is a copy paste error. –  Steven Jeuris Feb 26 '11 at 14:19
@squirrel: As for the faster once you have trained in it, I (and the paper) discusses why these results might be invalid. (Almost all 'trained' participants were trained in camelCasing and not underscores. A follow up study I found recently has the opposite outcome with people trained in underscores. I didn't have a chance to read it yet, and it seems temporarily down. –  Steven Jeuris Feb 26 '11 at 14:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.