🚀 go-pugleaf

In article <41tj89$2hn@deyke3.fc.hp.com>, rainer@deyke3.fc.hp.com says...
>
>Pete Becker (pete@borland.com) wrote:
>: In article <41ki32$p4t@deyke3.fc.hp.com>, rainer@deyke3.fc.hp.com says...
>: >Well, I prefer explicit types because they are so much clearer.  I
>: >consider typedefs to be extremely bad style, but I suppose it is a
>: >matter of personal preference.  The point I was making is that typedefs
>: >aren't necessary in C any more than in C++.  Sorry if I offended you.
>
>: "So much clearer"? Really? Which of these two is easier to read?
>
>: typedef void (*sigfunc)(int);
>: sigfunc signal(int sig, sigfunc func);
>
>: or
>
>: void (*signal(int sig, void (*func)(int)))(int);
>
>Well, for the first you will need to know what sigfunc is defined as
>before you understand it,

Yes, that's true.

> while the second is simply obvious to any
>programmer above the beginner level.
>

Really? I consider myself to be a fair amount above the beginner level, and I 
have to puzzle over things like the second. It's not "simply 
obvious".

>: I am not an idiot, and I will always use the first form rather than the 
>: second. Good code is written clearly, not cleverly.
>
>Well, what's so clear about 'sigfunc'?
>

It does one thing and one thing only. Once you grasp that one thing, it makes 
it much easier to understand what signal does. It's the same strategy we apply 
when we decompose complex operations into a series of simpler ones: divide and 
conquer. Unfortunately, programmers often get caught up in the macho attitude 
that complexity is good because it's challenging. Simpler is better.