allowing braces around suites

Antoon Pardon apardon at forel.vub.ac.be
Tue Aug 31 10:59:07 EDT 2004


Op 2004-08-31, Sam Holden schreef <sholden at flexal.cs.usyd.edu.au>:
> On 31 Aug 2004 10:33:07 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>> Op 2004-08-28, Isaac To schreef <iketo2 at netscape.net>:
>>>>>>>> "Kjetil" == Kjetil Torgrim Homme <kjetilho at yksi.ifi.uio.no> writes:
>>>
>>>    Kjetil> after all, code in _any_ language written by a
>>>    Kjetil> professional will have strict indentation.  so it's just
>>>    Kjetil> syntax.
>>>
>>> No.  In all other languages, people deal with *two* ways to find which
>>> statement is associated with an if/while/for/whatever statement and
>>> which is not: by looking at the indentation, and by looking at the
>>> braces.  They normally look at the indentation, since it is the
>>> quicker way.  But when they find something wrong, they look at the
>>> defining braces, sometimes deeply hidden in long expressions and
>>> statements combined into one line.  In Python, we have *one and only
>>> one* way to find which statement is associated with an
>>> if/while/for/whatever statement, and this is the quicker way that
>>> people are used to.
>>
>> I doubt that.
>>
>> I used to limit myself to indentation to see which code belonged
>> to which control. But then I found myself witch controls that
>> were so nested it was hard to see to which if a particular
>> else suite belonged and I started to use end markers in comments
>> to make the structure more visible.
>
> Deep nesting is a bad sign in itself,

Why?

> regardless of how a language
> specifies block structure. Making the code readable by removing
> the unreadable nesting seems a far better solution than adding
> end markers.

The nesting reflects the structure of the algorithm. If an algorithm
is best described by the nesting of a number of control structures
then i don't see how you are going to remove that nesting.

-- 
Antoon Pardon



More information about the Python-list mailing list