🚀 go-pugleaf

In article <11883:Jan502:21:0191@kramden.acf.nyu.edu>
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Every coding stylebook I've seen recommends that you give names to
>everything. It's a very good idea, you know.

Really?  Do you write

	#define ONE	1
	#define TWO	2
	#define TWENTYFOUR	24
	#define SIXTY	60
	secs = (((days*TWENTYFOUR + hours)*SIXTY + minutes)*SIXTY + seconds;
	for (j = ONE; ; j += TWO) ...;  /* step through odd integers */

in preference to

	secs = (((days * 24 + hours) * 60 + minutes) * 60 + seconds;
	for (j = 1; ; j += 2) ...;

?  Somewhere between that and

	#define BUFSIZE 4096
	char buffer[BUFSIZE];

which I hope everyone prefers to

	char buffer[4096]

there is a grey area, in which it's a matter of taste.  The vast majority
of functions fall one side of the line, but to deny the possibility that
a few fall the other [especially when, in some languages, extra expressive
power is obtained that way] seems unrealistic.

>Which is why you choose more meaningful names. Like fxpc, a function
>that adds c to x.

	I think I'd find "faddc" more expressive;  but anyway, it all gets
rather messy when the function delivers the absolute value of the difference
between the reciprocal third powers of r1 and r2 -- "famr3r1r2"?  Ugh!

>  #define FXPC \
>  double fxpc(x) double x \
>  { return x + c; }
>
>  z = 2 * sin(theta) * integral(fxpc, 0, pi) + ...;

	OK, that's quite neat for some simple cases (though I personally
don't like multi-line defines).  It has a snag:  I can imagine some very
hard-to-find bugs of the sort

	{ double c = some very messy expression;
	#define FXPC ... as above ...
	  z = ... integral (fxpc, 0, pi) ... + c + ... lots of uses of c;
	}

where the "c" that occurs in "fxpc" is not the one that occurs elsewhere
in the compound statement -- not too obscure if it leads to a compilation
error, but tuf if there just happens to be some global with the same name
and an appropriate type.

>> [anonymous functions]
>Who cares? How about because it's a pain to parse, compile, and read?

	Why is it easier to parse, compile or read a function body when
it's tacked on to a declaration than when it occurs elsewhere?  Is "7"
easier to read in "int i = 7;" than in "j += 7;"?

	[I'll get back to syntax and to anonymous functions in separate
articles, as the threads have diverged somewhat.]

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk