Guido sees the light: PEP 8 updated

[Ben Finney]

Marko Rauhamaa <marko at pacujo.net> writes:

> Chris Angelico <rosuav at gmail.com>:
>
> > What more often happens is that, once the function exceeds the
> > stipulated maximum, it gets split somewhat arbitrarily into a
> > "master" function and several "part" functions, with each part
> > having exactly one call site in the driver and exactly none
> > elsewhere. Even if the partial functions have reasonable names
> > (which they don't always), they're still tightly bound to the
> > master, and end up still functioning as a single unit.
>
> And? That's a feature, not a bug. It makes you analyze your approach a
> bit more. It makes you give names to things. It makes it more likely
> that your solution really works.

Yes. It also counters the tendency to let distant areas of code in a
function become too tightly dependent.

By identifying large functions with inherent “do this then do that then
do the other then …” structure as a problem in itself, the writer must
split it into small functions and think *explicitly* about how those
parts interact.

The interface between those parts is already part of the code design,
and if they're tightly coupled in a way difficult to describe simply, it
is a *bad* design already. A large function just obscures that, it
doesn't make it better.

Encouraging the split of large functions into small ones makes that
design explicit, and exposes places wehre the coupling is too complex or
too tight. The code writer is then explicitly and routinely thinking
about how best to narrow the coupling between the parts.

> > Unless you can genuinely make that subfunction useful in some other
> > context, there's not a lot of use splitting it into a function. You
> > don't generally see those perfect "paragraphs" in real-world code.

The point of splitting functions is not re-use (though that is a useful
side effect when it happens). The point is, in the face of trends that
are all toward code becoming difficult to understand and tangled, to
make the design as clear and simple and obviously correct as feasible.

-- 
 \     “Welchen Teil von ‘Gestalt’ verstehen Sie nicht?  [What part of |
  `\                ‘gestalt’ don't you understand?]” —Karsten M. Self |
_o__)                                                                  |
Ben Finney