7

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

squirrel
  • 181
  • 1
  • 5

3 Answers3

7

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

TZHX
  • 5,052
  • 2
  • 25
  • 32
5

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.

Community
  • 1
Steven Jeuris
  • 5,804
  • 1
  • 30
  • 52
  • 3
    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
  • 1
    @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](http://www.computer.org/portal/web/csdl/doi/10.1109/ICPC.2010.41) 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
0

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.

9000
  • 24,162
  • 4
  • 51
  • 79