allowing braces around suites

Antoon Pardon apardon at forel.vub.ac.be
Thu Sep 2 13:27:36 CEST 2004


Op 2004-09-01, Jeremy Bowers schreef <jerf at jerf.org>:
> On Wed, 01 Sep 2004 06:13:09 +0000, Antoon Pardon wrote:
>
>> If you need a function or class just to avoid nesting, then IMO
>> you have only camoeflaged it.
>
> If you are dividing your function merely on nesting grounds, you've missed
> the point.

Well then I think the point was ill brought.

> You'll find that if you do this correctly, you code more quickly, test
> more easily, and after practicing for a couple of years you will never
> again have the situation where you say to yourself "Gee, I'd really like
> to use that functionality over there, but it is so wrapped up in other
> extraneous garbage that it is easier to (do it from scratch/copy and
> paste/live without it)."

I haven't come up in such a situation for tens of years. So I think
I'm doing well enough.

I also have been programming enough to know that for every programming
rule to program in a readable fashion and producing easily maintainable
code, there are situation where it is better to break the rule then
to follow it if you really want readable and easily maintainable code.


> If you're dissing it, you haven't tried it. Why don't you try it for a
> while? Deeply nested functions are *bad*; continual use of them as an
> employee of mine would be a firing offense (after suitable warnings), on
> the grounds that code so produced has very limited worth compared to what
> it should have. Deeply nested functions are harder to understand, harder
> to debug, harder to re-use, harder to modify, harder to test, and all this
> and no advantages, too!

And from what number will you call something deeply nested?

Does that limit also apply if it is reached by having a number
of nested functions? I also found that you don't need that
many nested levels. Suppose you have the following situation:


|  def function
|
|    def localfunction
|
|      localfunction
|      code
|
|    function
|    code

My experience is that in such a situation, especially
if the local functions grows of you have more 
local functions it can become hard to see where the body
of the global function begins. Just looking at the
deindentation is not enough because that could be the
result of a control suite that ended. Using an endmarker
like #def can make finding the beginning of the main
function a lot easier and so make the code more readable
and maintainable.

-- 
Antoon Pardon



More information about the Python-list mailing list