Georg Wrede wrote:
> 
> 
> Daniel Keep wrote:
> 
>>
>> BLS wrote:
>>
>>> "Deewiant" <deewiant.doesnotlike.spam@gmail.com> schreef in bericht
>>>  news:e6rno9$1ju8$1@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? ;-(

Don Clugston wrote:
> Another important feature of the colon is that it can appear inside version{} blocks. You can't do this with the {} form.
> 
> version(Windows) {
> 
>   extern(Windows):
> 
> } else {
> 
>   extern(C):
> 
> }
> 
> // These are extern(Windows) on Windows systems, but
> // extern(C) on Linux.
> // For example, the MySQL functions behave this way.
> void func1();
> void func2();
> 

Hmm, sounds like a handy hack :)

Georg Wrede wrote:
> 
> 
> Daniel Keep wrote:
>>
>> [snip]
>>
>> 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!!
> 
> 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!

For me, it was Python that really changed how I code.  The first two times I tried to pick up Python, I just dismissed it as being another "weird" language.

The third time I tried, I finally groked functional programming.  All of a sudden, I could express complex ideas using lists and functions, combining them with a few simple operations.

Python's actually changed many aspects of my coding style, mostly for the better.

Java, on the other hand, taught me to hate identifiersWhichAreFullAndGramaticallyCompleteEnglishSentences ;)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/