Why "flat is better than nested"?

[Steven D'Aprano]

On Wed, 27 Oct 2010 14:02:27 +0000, kj wrote:

> I have nothing against humor.  The reason why I find "import braces"
> funny is that it is so obviously a joke.  But I do find it mildly
> annoying (and just mildly) that a joke/hoax/farce like ZoP/this.py is
> built into the standard lib, because a lot of people (not just me) don't
> realize it's a joke.

What makes you think it's a joke?


> I don't see the point
> of making the task any harder than it already is by injecting additional
> *gratuitous confusion* in the form pseudo-rogramming advice that
> apparently no experienced Python program really believes/takes seriously
> anyway.

You're badly misinformed if you think that Python programmers don't take 
the Zen seriously.

I dare say some don't, particularly those who like writing Lisp/Java/PHP/
whatever in Python. I also expect that some take it *too* seriously, as 
religious dogma.

Although the Zen is written in a light-hearted fashion, it is not 
intended as a joke. Every line in the Zen is genuine advice -- even the 
one about being Dutch. Would it help to write it out in a less light-
hearted fashion?



When programming in Python, you should:

Aspire to write beautiful, elegant code and algorithms, rather than ugly 
and messy.

Programming is about giving instructions to the computer. It is better to 
give those instructions explicitly, rather than implicitly based on the 
context -- context which may not be quite what you expect, or that the 
reader may not have recognized.

Simple code has fewer things to go wrong, less to understand, and fewer 
places for bugs to hide. Prefer simple code to complex code.

Complex problems may require complex solutions. But complicated solutions 
should be avoided if you can. A watch is complex; the rules of precedence 
and etiquette in the court of Louis the Sun King in 17th century France 
were complicated.

Flat data structures are typically easier and faster to parse, and should 
be preferred over nested data structures. Where you need nested data 
structures, prefer shallow rather than deeply nested.

You read source code much more often than you write it, and consequently 
readability of the code is important. Aim to maximize readability unless 
performance dictates compromising on readability.

Languages and libraries should aim for consistency and should support the 
general case. Resist the temptation to pile on support for special cases 
that are useless for nearly everybody. Let the caller handle their own 
special cases in their code.

Unless there are good, practical reasons for supporting a special case.

Errors should be treated as errors. Library code should always report 
errors that occur, and not just silently suppress them.

Users should have the option to explicitly silence errors they don't care 
about.

If a situation is ambiguous, functions should not try to guess what the 
caller meant. They will sooner or later get it wrong.

For each task the user wants to do, there should be an obvious way to do 
it. Preferably only one obvious way, but multiple solutions are allowed. 
If there is no obvious way at all, then the language or library is 
lacking.

Sometimes what is obvious to Python's designer, Guido van Rossum, who is 
Dutch, may not be obvious to anyone else who doesn't share his 
background. Live with it.

If something needs doing, it is better to do it now than to procrastinate 
and never get it done. Don't wait for software to be perfect -- you can 
measure many things with a ruler with a notch in the side, and even a 
blunt saw cuts better than no saw at all.

But sometimes it is better to do without than to lock yourself into a 
faulty standard. If there's no solution that's good enough right now, it 
may be better to wait for one than to be stuck forever on a bad solution.

If the implementation of software is complicated and hard to explain how 
it works, it is probably a mistake to go down that path. Find a better 
implementation.

If the implementation is simple and easy to explain, it may be a good 
idea. But some ideas are just bad, regardless of whether they are easy to 
implement or not.

Namespaces are a tried and tested solution to many programming jobs. We 
should use them more often in Python.

535 words instead of 137. I prefer the Zen.


You'll note that some of the maxims are general rather than specific to 
Python. Some might argue that *all* the maxims are perfectly general, and 
the fact that other languages make other choices is their loss.


-- 
Steven