allowing braces around suites

[Sam Holden]

On 31 Aug 2004 14:59:07 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
> 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?

Because it is often hard to read - as you stated by saying you needed
to add end markers to make the structure more visible.

"Nest as deeply as you can." is one of the obfuscation techniques,
recommended in "How To Write Unmaintainable Code"[1] (and it is
refering to languages which use {}s), so there is some evidence
this is an opinion held by more people that just me...

It often goes hand hand in hand with long functions, which 
I also assert are hard to read.

1. http://mindprod.com/unmain.html

>
>> 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.

Functions, classes if the state requirements are such that you would
be passing too many arguments to/collecting too many results from each
function.

Readability counts, and all that...

-- 
Sam Holden