{"id":1071,"date":"2009-11-14T17:58:18","date_gmt":"2009-11-14T07:58:18","guid":{"rendered":"http:\/\/www.somethinkodd.com\/oddthinking\/?p=1071"},"modified":"2009-11-14T17:58:18","modified_gmt":"2009-11-14T07:58:18","slug":"python-codingstyle-ishated-true","status":"publish","type":"post","link":"https:\/\/www.somethinkodd.com\/oddthinking\/2009\/11\/14\/python-codingstyle-ishated-true\/","title":{"rendered":"python.CodingStyle().ishated = TRUE"},"content":{"rendered":"<div class=\"aside\">This is a bit unpolished, but I need to reboot my computer, and if I save this file I will never get around to opening again, which is one of the many, many reasons I have been so quiet lately.<\/div>\n<p>I believe the correct approach to coding standards and style guidelines comes in by two separate yet equally important obligations.<\/p>\n<p>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.<\/p>\n<p>The second is to go ahead and follow it anyway.<\/p>\n<p>I&#8217;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.<\/p>\n<hr \/>\n<p>The Python Programming Language comes with its own <a href=\"http:\/\/www.python.org\/dev\/peps\/pep-0008\/\">Style Guide for Python Code<\/a>.<\/p>\n<p>Here are some places where the coding standard is just. so. wrong.<\/p>\n<ul>\n<li>Line continuation characters are preferred over brackets. Line continuation characters are evil, especially in a world where an invisible whitespace character can break it.<\/li>\n<li>Spaces after every comma? Too much!<br \/>\n<code>(x,y) = (1,4) # That's fine!<\/code><\/li>\n<li>Spaces around % operator? Why?<br \/>\n<code>print \"The square of %d is %d\"%(x,x*x)<\/code><\/li>\n<li>&#8220;You should use two spaces after a sentence-ending period&#8221; if you are using a type-writer in 1975.<\/li>\n<li>&#8220;Use inline comments sparingly&#8221; should read &#8220;Use inline comments daringly.&#8221;\n<p>(Props to the children&#8217;s book I stole the sparingly\/daringly joke from. It was called &#8220;[something] Jack&#8221;. Invisible Jack? I wish I could remember.)<\/li>\n<\/ul>\n<h3>Naming Standards<\/h3>\n<p>Mostly, my complaints relate to the naming conventions.<\/p>\n<p>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 <a href=\"http:\/\/www.somethinkodd.com\/oddthinking\/2005\/10\/27\/the-case-for-case-preserving-case-insensitivity\/\">case-sensitive<\/a>. I believe there was a concerted effort in Python 3.0 to clean this up.<\/p>\n<p>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&#8217;s like it was chosen by a committee to make theCamelCasers and the_underliners equally miserable. That is quite unusual for Python, where the <a href=\"http:\/\/en.wikipedia.org\/wiki\/Benevolent_Dictator_for_Life\" title=\"Wikipedia definition of Benevolent_Dictator_for_Life\" class=\"wikipedia\">Benevolent Dictator For Life<\/a> decision structure avoids the design-by-committee feel.<\/p>\n<p>I am influenced by the original Booch Components (Not the new-fangled <a href=\"http:\/\/booch95.sourceforge.net\/\">Ada-95<\/a> 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 &#8211; so you can reference the collection called &#8220;Queue_Unbounded_Managed_Balking_White_With_Two_Sugars&#8221; as &#8220;Queue&#8221; in your code.<\/p>\n<p>To me, having long descriptive names appear once at the time of import is <em>exactly<\/em> where you want to put that level of detail, and then, specified once, it should never need to appear again.<\/p>\n<p>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 &#8220;Queue&#8221;. Too bad if you want to have a simpler, non-thread-safe queue &#8211; the namespace is already polluted.<\/p>\n<div class=\"aside\">&#8220;Queue&#8221; fails one of the other coding standard requirements. Because some operating systems are case-insensitive, all module names should be lower-case.<\/div>\n<p>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! <\/p>\n<p>(Of course, the old <a href=\"http:\/\/www.somethinkodd.com\/oddthinking\/2005\/10\/27\/the-case-for-case-preserving-case-insensitivity\/\">file_name versus filename<\/a> problem will still confuse me.)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The first obligation when faced with coding standards and style guidelines 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_s2mail":"","footnotes":""},"categories":[21,34,1],"tags":[],"class_list":["post-1071","post","type-post","status-publish","format-standard","hentry","category-observation","category-software-development","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1071","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/comments?post=1071"}],"version-history":[{"count":4,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1071\/revisions"}],"predecessor-version":[{"id":1075,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/posts\/1071\/revisions\/1075"}],"wp:attachment":[{"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/media?parent=1071"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/categories?post=1071"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.somethinkodd.com\/oddthinking\/wp-json\/wp\/v2\/tags?post=1071"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}