OddThinking

I believe the correct approach to coding standards and style guidelines comes in by two separate yet equally important obligations.

The first is to argue about, moan about and mock the appalling choices made by the so-called developers who came up with a style that is guaranteed to turn your code into an unreadable, unmaintainable mush.

The second is to go ahead and follow it anyway.

I’ve recently been encouraged to follow a coding standard, as the Python project I am working on now has more than one developer. This article is my attempt to satisfy the first condition, now that my code satisfies the second.

The Python Programming Language comes with its own Style Guide for Python Code.

Here are some places where the coding standard is just. so. wrong.

• Line continuation characters are preferred over brackets. Line continuation characters are evil, especially in a world where an invisible whitespace character can break it.
• Spaces after every comma? Too much!
  (x,y) = (1,4) # That's fine!
• Spaces around % operator? Why?
  print "The square of %d is %d"%(x,x*x)
• “You should use two spaces after a sentence-ending period” if you are using a type-writer in 1975.
• “Use inline comments sparingly” should read “Use inline comments daringly.”

  (Props to the children’s book I stole the sparingly/daringly joke from. It was called “[something] Jack”. Invisible Jack? I wish I could remember.)

Naming Standards

Mostly, my complaints relate to the naming conventions.

I am not just referring to the number of Python libraries that break the convention. A great shame. Really, it is a major language suck, especially given the silly idea to make the language case-sensitive. I believe there was a concerted effort in Python 3.0 to clean this up.

I am also talking about using different styles in different places. Module names use a different style to class names, which use a different style to function names. Make up your mind! It’s like it was chosen by a committee to make theCamelCasers and the_underliners equally miserable. That is quite unusual for Python, where the Benevolent Dictator For Life decision structure avoids the design-by-committee feel.

I am influenced by the original Booch Components (Not the new-fangled Ada-95 version) in which the package name documents excruciating detail about the components memory-management model, time and space semantics and the like. The first act of importing a new component is to alias it – so you can reference the collection called “Queue_Unbounded_Managed_Balking_White_With_Two_Sugars” as “Queue” in your code.

To me, having long descriptive names appear once at the time of import is exactly where you want to put that level of detail, and then, specified once, it should never need to appear again.

Python is influenced by some operating systems having restricted filename lengths. Therefore, they recommend short names for modules. Their bounded, thread-safe, blocking queue is called “Queue”. Too bad if you want to have a simpler, non-thread-safe queue – the namespace is already polluted.

The other rule that really gets me annoyed is that local variable and function names should only have underscores where it improves readability. NOOO! That is a subjective call, which is unreplicable. I cannot remember whether my method was called httpserver or http_server; it depends whether I thought it would be hard to read later at the moment I wrote it. Make the underscore mandatory, and save my brain cells!

(Of course, the old file_name versus filename problem will still confuse me.)