allowing braces around suites

[Antoon Pardon]

Op 2004-09-01, Steve Holden schreef <sholden at holdenweb.com>:
> Antoon Pardon wrote:
>
>> Op 2004-08-31, Ville Vainio schreef <ville at spammers.com>:
>> 
>>>>>>>>"Antoon" == Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>
>>>   Antoon> The nesting reflects the structure of the algorithm. If an
>>>   Antoon> algorithm is best described by the nesting of a number of
>>>   Antoon> control structures then i don't see how you are going to
>>>   Antoon> remove that nesting.
>>>
>>>Functions and classes?
>> 
>> 
>> If you need a function or class just to avoid nesting, then IMO
>> you have only camoeflaged it. In order to understand what is
>> going on you still need to understand how the nesting of
>> a number of controls prroduce a certain result and when
>> you write a function just to avoid nesting it often enough
>> makes readablity harder.
>> 
> I'm afraid that's bollocks, equivalent to saying that building an 
> airliner by connecting subassamblies together is just camouflaging the 
> complexity.

No it is not.

Those subassemblies each have their own function. Usually you
can even use subassemblies to build different planes.

But if something is complex and for whatever reason not easily
divided in subassemblies than just picking a number of things
that are in each others neighbourhoud and calling that a
subassembly won't accomplish much. And that is eactly what
you do if the only reason for making something a function
is because the code in question was nested too deep.

> Presumably your chosen method would be to assemble a pile of all the 
> parts and then just stick them together one by one? God help the test 
> pilot if so...

Well you presume wrong.

> [One of] the point[s] about classes and functions is precisely that they 
> do allow you to reduce the complexity by providing repeatable unit 
> behavior which you can test before you rely on them in your higher-level 
> logic.

So? That doesn't mean you should define one, just because some
code was nested too deep.

> The alternative is monolithic programs, which are well known to be 
> difficult to compile and maintain.
>
> If your program logic is too deeply nested with conditions then 
> functions and classes provide a powerful logical abstraction to fight 
> the complexity and improve code reliability and maintainability.

Only if that code has some usefull abstraction. Just putting some
code in a function doesn't provide any usefull abstraction.

-- 
Antoon Pardon