Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: Nicolas George on 5 Mar 2010 04:49 Ike Naar wrote in message <hmqg50$uf4$1(a)news.eternal-september.org>: > If you read my code, it would be unfortunate if you would conclude, from the > bare fact that I wrote the addition as (a+b), that a is the larger of > the two. It does not work that way. If you do not know anything about the variables, then "x + q" and "q + x" will not mean anything to you. On the other hand, if you know that x is the reference and q the cursor, then the meaning of "q + x" will be more immediately obvious if it is written "x + q". That is not a concious process, just a matter of mind nimbleness. Consider natural languages: some of them put the verb at the end of the phrase (Latin, Japanese, German when it's a compound verb), but as far as I know, most put the subject / theme of the phrase near the beginning. Because, semantically and not grammatically, the subject / theme is the core around which the complements, including the verb revolve. > while (left < right) Why did you not write "while (right > left)"? And why does everyone write "array[index]" instead of "index[array]"?
From: Nicolas George on 5 Mar 2010 05:22 Stefan Ram wrote in message <index-20100305105826(a)ram.dialup.fu-berlin.de>: > �index[ array ]� actually is very natural If it were natural, people would use it. > as it is like what > mathematicians call a �projection�, for example to get the > coordinate 1 of the point x =( x�, x�, x� ), one uses the > projection �p��, thus x� = p�( x ), where x� is the coordinate > 1 of x. It _does_ the same thing, but it does not _mean_ the same thing.
From: Richard Heathfield on 5 Mar 2010 05:45 Seebs wrote: > On 2010-03-05, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Seebs wrote: >>> When I see "if (x != y)" in C, I >>> unconsciously perceive it to be the case that x could vary and y couldn't. > >> Why? > > Because it's idiomatic, and most of the time, code follows that idiom. I don't see how you get that y can't vary, just from seeing if(x != y). That's not an idiom - in fact, it's a ma short of idiomatic[1]. != takes two values; neither of them has to be a constant, and it's not terribly unusual to find that neither of them /is/ a constant. > >>> 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". > >> Why? > > Idioms don't have to have any reason other than "that's how it's been done > before". It's been done both ways before. > It's a communications tool; given a general pattern that it's the > varying part on the left, and the invariant part on the right, that's what > I expect whenever I see a comparison operator. Then, much of the time, you expect the wrong thing, since much of the time there is no invariant involved. If you were reading my code, you would very often find that, where an invariant /is/ involved in a comparison for equality, it's on the left. So your preconceptions would mislead you. >>> 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. > >> Why? > > Because that's how the majority of code has been written. I am always suspicious of "we do it this way because most people do it this way". Sturgeon's Law and all that. I'm not saying we should do Y *because* most people do X; but following the crowd *just* for the sake of following the crowd is very often a bad idea, because the crowd is very often heading in the wrong direction. <snip> >>> If someone wrote this loop, then altered max >>> within the loop while modifying i to keep it constant, it would be completely >>> incoherent. > >> Why? Consider: an ordinary reversal loop: > >> while(f < h) >> { >> e = a[f]; >> a[f++] = a[h]; >> a[h--] = e; >> } > >> Which is the constant now? Should it be f<h, or h>f? (Strictly, they're >> not equivalent, but in this case either will do.) > > Indeed, in that case, either will do. Sure. So which one is the constant you were expecting to see? > But in many cases, there's a clear preference, and even if you don't share > it, you will understand most code better and/or more quickly if you keep > that pattern in mind. I find it easier to keep in mind what the operators do with their operands. <snip> >>> [...] If we flip the components of the >>> middle expression, we've suddenly gone off the standard idiom > >> C&V please. > > K&R. I don't think you'll find a single test in there which goes the > other way. That's a rather weak basis for claiming a "standard idiom". <snip> [1] A bit OTT, but I couldn't resist using the idiom(!) -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Rainer Weikusat on 5 Mar 2010 07:24 ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Keith Thompson <kst-u(a)mib.org> writes: >>>But it does mean equality. In fact, it commands it. >>Not for volatile objects or NaNs. > > Not even for some other usages: > > #include <stdio.h> > #include <limits.h> > > int main( void ) > { char c = INT_MAX; > printf( "%d\n", c == INT_MAX ); } > > �=� is a write operation. Of course it does. You are just playing games with automatic conversions in the hope to confuse less knowledgable readers. The line char c = INT_MAX has implementation defined behaviour (although the gcc warning 'overflow in implicit constant conversion' suggests that the people-with-an-axe-to-grind who already managed to convert their pointless political statement about "proper integers" to code in various other places are still seeking for a way around the requirement to support the traditional, sane and useful behaviour ....). If the result is not that 'an implementation defined signal is raised', an 'implementation defined automatic conversion' is supposed to happen. Assuming that no such signal was raised and that sizeof(int) > 1, INT_MAX cannot be converted to char without 'loss of information'. The expression c == INT_MAX causes the value stored in C to be converted back to int. Of course, after char c = (char)INT_MAX was performend, (int)c == INT_MAX cannot be true if sizeof(int) > 1. The correct comparison would thus be c == (char)INT_MAX
From: Ersek, Laszlo on 5 Mar 2010 09:22
In article <OIidndrfAtccKg3WnZ2dnUVZ8sCdnZ2d(a)bt.com>, Richard Heathfield <rjh(a)see.sig.invalid> writes: > Seebs wrote: > > <snip> > >> When I see "if (x != y)" in C, I >> unconsciously perceive it to be the case that x could vary and y couldn't. > > Why? Because he pronounces it as "x is not equal to y", and the subject of that sentence is "x". "x" is the actor, the variable that is acting. "y" is part of the prepositional phrase, it is static. >> Consider: >> for (i = 0; i < 10; ++i) >> >> Why do we write "i < 10" rather than "10 >= i"? > > Good question. .... It's either me, or now two of you not noticing (or ignoring) that "10 == i" satisfies the second but not the first. >> 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". > > Why? Because programmatically, "i" changes over time, 10 does not, and when one reads out loud the controlling expression in English, the subject of that sentence ("the actor") should be the entity that is acting. > >> 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. > > Why? Because when read out loud, "i" is the subject. >> The time when that technique caught something compilers wouldn't catch >> is long gone. I don't think it's needed anymore. > > You'd be amazed at the antiquity of some compilers. At one recent site, > I was somewhat surprised to find an entire project team still using > MSC5.00a (and they seemed perfectly contented, too). The following version of gcc: gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) displays no warning for the following: $ gcc -Wall -Wextra -ansi -pedantic -fsyntax-only try.c ----v---- static int f(int a) { return a = 3; } static int g(int a) { return (a = 3); } ----^---- (Yes, we could fix that by taking "a" as const.) Another example, showing that extra parentheses can shut up gcc: ----v---- int f(void); static void g(void) { int a; a = f(); if ((a = 2) || (a = 3)) { /* ... */ } } ----^---- This produces no warnings either. Although the parentheses are not needed for the intended meaning, that is, for a == 2 || a == 3 some people might find the parenthesized version more readable, and when they combine that with typing assignment instead of equality, then (this version of) gcc won't warn them. Cheers, lacos |