allowing braces around suites

[Antoon Pardon]

Op 2004-08-31, Sam Holden schreef <sholden at flexal.cs.usyd.edu.au>:
> 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.

That is IMO not a problem of the nesting but the problem of a language
that doesn't provide a clear mark for when a nesting ends.

In python when you enter a nesting, that is always clear because
entering always happens one level at a time. But leaving a nesting
is not so clear because you can leave more then one nesting at the
time.  This makes it less readable. Providing end markers would
provide the same visible clues about leaving a nesting as there
already are for entering.

Sure you can avoid indentation by writing functions. But IMO that
only helps if you can abstract some part of the algorithm. If no
names comes to mind for how to call such a function writing such
functions IME makes the code less readable.

End yes sometimes your code is still not readable with end markers.
In that case the nesting is indeed the reason why the code is not
readable and you better look for a way to refactor your code.

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

That one go to extremes in nesting so that no visible clue will
help you in understanding what is going on is certainly true,
but it doesn't contradict that more visible clues can make
things more readable.

> It often goes hand hand in hand with long functions, which 
> I also assert are hard to read.
>
> 1. http://mindprod.com/unmain.html

I only rarely write long functions.

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

Yes and IMO readability can sometimes more be helped by having end
markers then by dividing your code in functions just to avoid deep
nesting.

Just as sometimes readbility is harmed more by dividing that long
function then by keeping it.

-- 
Antoon Pardon