How do you think about the flooding of bracket?

[Hasan Aljudy]

Georg Wrede wrote:
> 
> 
> Daniel Keep wrote:
> 
>>
>> BLS wrote:
>>
>>> "Deewiant" <deewiant.doesnotlike.spam at gmail.com> schreef in bericht
>>>  news:e6rno9$1ju8$1 at digitaldaemon.com...
>>>
>>>>> I find something like that gets very annoying quickly, when
>>>>> "PROCEDURE
>>>
>>>
>>> xyz" is
>>>
>>>> one or two lines long. Imagine something like (mixed-syntax
>>>> pseudocode):
>>>
>>>
>>> Hi Deewiant, a two line inner function seems , at least to me, to
>>> be a quit seldom used construction.
>>
>>
>> Well, that depends on your coding style, really.
>>
>> Personally, I prefer to write lots of small, well-defined functions.
>> If I can't fit a whole function's flow into my head at once, then I
>> know I need to break it up.
> 
> 
> Kudos, Daniel, for saying that!!

ditto!

That's exactly what I do.

> 
> I used to write long functions, but then I got a peek at Turbo Pascal 
> 5.5 library source code, and I was simply astounded. Very few of the 
> functions (or procedures) were more than 5 lines of [actual] code!
> 
> I think this was the reason why Borland was able to release new versions 
> of their Pascal and the IDE, quite often, and had very few bugs in them. 
> This coding style is actually encouraged in Java documentation, and the 
> compiler is supposed to optimise away much of the "unneeded function 
> calls", and do automatic inlining of stuff that gets only used in a 
> couple of places -- by default.
> 
>  From that day on, I myself could tackle much bigger projects, and 
> modifying and rewriting became pleasant, instead of being a nightmare.
> 
> (I think programming is taught in such a way that people don't get in a 
> habit of, or see the value in, keeping functions short.)
> 
> Another thing they used was function and identifier names that let the 
> naive reader instantly see what was going on. (Sure, it takes "more 
> ink", but when somebody else has to edit your code one day, the 
> difference is like night and day.)
> 
>> One interesting approach to this problem I've seen is in Nemerle: it 
>> supports both C-style syntax and, with the flip of a compiler switch,
>>  Python-style indenting.
> 
> 
> Dot Net, anyone? ;-(