Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!keele!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: Complexity of syntax Message-ID: <1991Jan8.165344.13870@maths.nott.ac.uk> Date: 8 Jan 91 16:53:44 GMT References: <1990Dec29.101233.1894@mathrt0.math.chalmers.se> <18747:Jan220:02:1091@kramden.acf.nyu.edu> <1991Jan4.152846.15917@maths.nott.ac.uk> <11883:Jan502:21:0191@kramden.acf.nyu.edu> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 73 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