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