Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: William Ahern on 4 Mar 2010 23:53 In comp.unix.programmer Ike Naar <ike(a)localhost.claranet.nl> wrote: > In article <87vddcdp8o.fsf(a)fever.mssgmbh.com>, > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > >John Gordon <gordon(a)panix.com> writes: > >It is a bad idea to try to solve social problems with technical > >means. The problem behind this is that = in C is a so-called 'false > >cognate' for people who are intimately familiar with mathematics, that > >is, a term in a foreign language which 'looks' very similar to a > >loosely related term in one's mother tongue, but with a (subtly) > >different meaning. This means that such people will likely confuse = > >and == in C intuitively and have a hard time spotting such an error > >since the text 'looks right' according to the set of conventions they > >are so used to that they no longer actively think about them. > > > >But this really only means that average people well-versed in > >mathematics shouldn't attempt to code in C because they will likely > >make basic errors other people wouldn't. > Using ``='' for something other than equality was, in my opinion, the > most unfortunate design decision in the design of C. But it does mean equality. In fact, it commands it.
From: Ike Naar on 5 Mar 2010 01:00 In article <slrnhp0j1q.eil.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)seebs.net> wrote: >On 2010-03-04, Ike Naar <ike(a)localhost.claranet.nl> wrote: >> It's also "non chinese" and "non swahili". It's C, and in C the order >> of the operands of the == and != operators is irrelevant. > >To the compiler, yes. To the reader, no. To the mathematically inclined reader, yes. >> You don't read arithmetic expressions like you read a work of literature. > >You sort of do, actually. >In general, while everyone knows that addition is commutative, people will >tend (slightly) to see "x + 3" as "basically x, but with 3 more", and "3 + x" >as "basically 3, but with x more". The lefthand operand has primacy, and >this *does* matter. It doesn't matter, but anybody can fool themselves that it does. And then Alice convinces herself that 3+x is ugly and unreadable, Bob opts for x+3 being error-prone and unreadable, and now what should Carol write? > [snip] > >It's like indentation. We don't indent in C because the compiler cares, but >because it helps readers understand. Bad indentation can result in readers >misunderstanding code, because they trust the indentation to be a cue. Fully agreed. But there a several (conflicting) styles of indentation that are considered 'good', and a programmer should be able to understand code that uses a reasonable indentation style. It makes no sense to convince oneself that a reasonable style is "unreadable" simply because it's not one's preferred style. >Similarly, reversing the order of the comparands in an equality or inequality >comparison, even though in theory it changes nothing semantically, can cause >readers to misunderstand code. >I write for humans, not compilers. Compilers aren't subject to assumptions, >or to difficulty keeping track of the code. Humans, you can't please them all ;-)
From: Vladimir Jovic on 5 Mar 2010 01:33 Casper H.S. Dik wrote: > Keith Thompson <kst-u(a)mib.org> writes: > >> ``pointer1 =! NULL'', of course, parses as ``pointer1 = !NULL''. >> ``!NULL'' evaluates to 1, and assigning an int value (other than a >> null pointer constant) to a pointer object requires a diagnostic. > > And for other types the compiler or lint will also create a > diagnostic. > > (4) warning: assignment operator "=" found where "==" was expected > (4) warning: constant operand to op: "!" Cool. I didn't know I would get a warning.
From: Seebs on 5 Mar 2010 01:37 On 2010-03-05, Ike Naar <ike(a)localhost.claranet.nl> wrote: > In article <slrnhp0j1q.eil.usenet-nospam(a)guild.seebs.net>, > Seebs <usenet-nospam(a)seebs.net> wrote: >>On 2010-03-04, Ike Naar <ike(a)localhost.claranet.nl> wrote: >>> It's also "non chinese" and "non swahili". It's C, and in C the order >>> of the operands of the == and != operators is irrelevant. >>To the compiler, yes. To the reader, no. > To the mathematically inclined reader, yes. I disagree. I was raised by mathematicians, but I view statements and expressions as often being written to communicate additional meaning. > It doesn't matter, but anybody can fool themselves that it does. The existence of even a small set of people to whom it matters means it matters, because code is written for programmers first, and compilers second. > Fully agreed. > But there a several (conflicting) styles of indentation that are > considered 'good', and a programmer should be able to understand > code that uses a reasonable indentation style. It makes no sense > to convince oneself that a reasonable style is "unreadable" simply > because it's not one's preferred style. "convince oneself" implies a volitional act taken contrary to evidence or experience. I don't think that's involved here. I wouldn't quite call it "unreadable", but it certainly reduces my chances of following code correctly on the first try. When I see "if (x != y)" in C, I unconsciously perceive it to be the case that x could vary and y couldn't. Consider: for (i = 0; i < 10; ++i) Why do we write "i < 10" rather than "10 >= i"? Because i's the one that varies, so "i is less than ten" is more idiomatic than "ten is greater than or equal to i". Now consider: for (i = 0; i < max; ++i) even though "max" may vary over time, the assumption is that, for this loop, i changes and max doesn't. If someone wrote this loop, then altered max within the loop while modifying i to keep it constant, it would be completely incoherent. So, now... for (l = head; l != NULL; l = l->next) Clearly, this follows the same idiom. If we flip the components of the middle expression, we've suddenly gone off the standard idiom for the condition in a for loop, and the reader is justifiably surprised. And if the for loop should have "l != NULL" rather than "NULL != l" (and it should), then so should an if statement, for consistency. The time when that technique caught something compilers wouldn't catch is long gone. I don't think it's needed anymore. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Keith Thompson on 5 Mar 2010 02:41
William Ahern <william(a)wilbur.25thandClement.com> writes: > In comp.unix.programmer Ike Naar <ike(a)localhost.claranet.nl> wrote: [...] >> Using ``='' for something other than equality was, in my opinion, the >> most unfortunate design decision in the design of C. > > But it does mean equality. In fact, it commands it. Not for volatile objects or NaNs. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" |