[Python-ideas] Another indentation style

Steven D'Aprano steve at pearwood.info
Mon Sep 2 03:28:53 CEST 2013

On 01/09/13 21:10, Rob Cliffe wrote:

> In Python, writing multiple code statements on a single line, especially with a semi-colin, appears to be a taboo roughly on a par with appearing naked in public.  But I believe that there are times when it is the clearest way of writing code, viz. when it makes visually obvious a *pattern* in the code.
> Here is one example, not very different from some "real" code that I wrote:
> def test(condition, a, b):
>      if condition=='equals'          : return a==b
>      if condition=='is greater than' : return a>b
>      if condition=='contains'        : return b in a
>      if condition=='starts with'     : return a.startswith(b)
>          etc.

I believe that the pattern is *more* readily apparent written the conventional way:

def test(condition, a, b):
     if condition=='equals':
         return a==b
     if condition=='is greater than':
         return a>b
     if condition=='contains':
         return b in a
     if condition=='starts with':
         return a.startswith(b)

You can run your eye down indent level 2 and see "condition return condition return condition return", which avoids needing to scan left-to-right (which is a significant slowdown when skimming code), and the distraction of that great big river of whitespace running down the middle of the block.

Another issue is the time spent deleting and inserting spaces in the middle of the lines to keep the return statements lined up after edits. With no clear benefit, that's just unproductive make-work. (But good if you're paid by the hour and your boss doesn't cotton on to what you are doing *wink*)

Later in your post, you write:

> And you may have an even better way.
> Again - not really the point.

But that precisely is the point! If the layout of code is obscuring the ways it can be simplified, generalized or refactored, then the layout is *actively* harmful. Now, maybe you have a reason for preferring a long list of if...return statements instead of the more usual idiom of a dict lookup. I don't understand your code to comment on that. But it is obvious to me that splitting the if...return over two lines certainly doesn't hurt the ability to visualise the pattern in the code, and probably helps make it even more clear.

> And here is some real code that I wrote (not worth explaining in detail).  I am sorry that it breaks another convention, having lines longer than 80 characters - this happens not be inconvenient for me, and was the best authentic *real* example I could find without spending a long time searching:
>          assert PN[0].isalpha()    ; FirstPart  = PN[0] ; PN = PN[1:].lstrip(Seps) # Must be a letter
>          if PN[0].isalpha()        : FirstPart += PN[0] ; PN = PN[1:].lstrip(Seps) # May be a second letter

That second line uses a layout that I wish was a SyntaxError, because it is ambiguous whether

if cond: statementA; statementB

should be grouped as follows (using braces as visual aids):

if cond:
     { statementA; statementB }

or like this:

{ if cond: statementA }

Such a shame that it is allowed. I can just count myself fortunate that I've never seen it before in the wild.


More information about the Python-ideas mailing list