Stylistic questions on UNIX C coding.
in [Unix Programming]
|
Prev: integer
Next: shared memory question
From: ImpalerCore on 5 Mar 2010 13:03 On Mar 5, 12:13 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote: > In article <4JydnbCdGNgatgzWnZ2dnUVZ7rydn...(a)bt.com>, > > Richard Heathfield <r...(a)see.sig.invalid> writes: > > Ersek, Laszlo wrote: > >> Because when read out loud, "i" is the subject. > > > Again, your comment would only be relevant if this were English, which > > it isn't. > > Exactly -- I'm a staunch member of the "7 == x" camp. I just tried to > explain why, as I perceive, Seebs thinks what he thinks. (Sorry if this > qualifies as bad etiquette.) Are you a staunch member of the '7 == x' because of style, or because of the possibility of catching '7 = x' errors? I personally don't like the style simply because it *is* more mind taxing, and it's a result of not seeing code in that style, not writing code in that style, and not thinking about code in that style, for about 8 years between C++ and C, that my brain has been conditioned that way. I would be bold enough to say that a large majority of C programmers are conditioned that way, simply from other people's code and books that I've seen. Perhaps you would allow me to scramble the characters on your keyboard in a way of my choosing that is better? Let's take 'asdfjkl;' and make it 'arstenil' since those d, f, j, k, and ';' characters are used much less often, and it requires more finger movement, causing more cases of carpal tunnel syndrome. Would you be willing to give that a try? The example is a bit hyperbolish, but that's how it feels to me looking at '7 == x'. And the thing is that you may actually like that keyboard better, but everyone else will still use the standard keyboard, and still complain if they have to use your keyboard. The inertia of the original style 'x == 7' is too large enough to overcome unless that style has generated so many problems that I'm motivated to try out '7 == x'. If you suffered from carpal tunnel syndrome, you may be tempted to give the new keyboard a try. I actually went through this process with single line if statements. if ( condition ) statement; I have been bitten by this syntax (spending hours pouring over code where my brain is not registering the syntax error) so many times that the bracket style if ( condition ) { statement; } has become my convention. It has saved me time because for whatever reason, my brain can deal with the syntax errors better. Lastly, I have no problem with someone wanting to use '7 == x' if it really does help them from a style perspective. I have an issue when people use the style just to catch '7 = x' errors when 'x == 7' would be easier to understand. Hey, I still use 'char* p' simply because I started in C++ and moved to C, and it's easier for me to use. I'm sure there are a host of people that will belittle me for still using that syntax, and I realize I may be in the minority, but I'll still keep using it since it's more work to relearn and restyle the code I've already written than to appease the majority. Again, if I have to work with a team, and it's decided to use 'char *p', I will gladly acquiesce, but unless I'm forced to code that way for a long time, I don't foresee myself changing my ways. Best regards, John D. > Cheers, > lacos
From: Seebs on 5 Mar 2010 13:11 On 2010-03-05, Ike Naar <ike(a)localhost.claranet.nl> wrote: > In article <slrnhp1a11.hqg.usenet-nospam(a)guild.seebs.net>, > Seebs <usenet-nospam(a)seebs.net> wrote: >>I disagree. I was raised by mathematicians, but I view statements and >>expressions as often being written to communicate additional meaning. > But you must be careful not to assign additional meaning if it was > unintended by the author. You can never avoid both Type 1 and Type 2 errors completely. For the most part, the benefits of assuming that idioms are intentional massively outweigh the costs of perceiving an idiom was not intended. > 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. And I wouldn't draw any such conclusion. I might, however, think that a was in some way the "base" value. a[i] is in theory equally equivalent to both *(a+i) and *(i+a). However, it is EXTREMELY unusual to write i+a -- because we know that we are adding an offset to a pointer, not adding a pointer to an offset. That they do the same thing doesn't matter. The pointer is the one which tells us what the operation is doing. > But that perception could be misleading. Yes, it could. Heuristics don't have to be 100% reliable to be worth using. > Another reason might be that "i < 10" and "10 >= i" are not the same thing. Whoops. >, not >=. I'm bad at symmetry sometimes. Or alternatively, probably, "9 >= i". -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: Seebs on 5 Mar 2010 13:19 On 2010-03-05, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > I don't see how you get that y can't vary, just from seeing if(x != y). I don't. I just get the impression that it is much less likely to be the member whose value is in question. And I'd guess that if you took a random sample of C code (say, a hundred lines from each of a couple thousand projects), you'd find that this was true in the VAST majority of cases. Well over 90%. Note that a limit like "max" is invariant *in context*, normally. while (i < len) usually means that, for the duration of the loop, i will be changing and len won't. Not always, but it's true often enough that exceptions are surprising. > It's been done both ways before. But one of them much, much, more often. > 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. With your code, yes. So I'd realize you were one of the people who does it the other way. Same as, if I went to England and noticed people driving on the wrong side of the road, after a couple of hours I'd be used to that. > 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. There is no significant objective advantage to either... But, as with the side of the road, there is a substantial advantage to having everyone agree. > Sure. So which one is the constant you were expecting to see? Neither. But I'm fine with a heuristic being imperfect. They are. It's just that, IF there is one that's more changeable than the other, I expect it to be on the left. >> 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". It works for 1TBS. And again, consider why it is that every test in K&R, and in King's book (I believe), and anywhere else I've looked, uses the same idiom. One of the reasons is that, having seen it that way, people tend to expect it and write it that way, and the net result is additional communication. It's like indentation. We indent code to make it reasonable. We do not, to borrow your phrase, "keep in mind what the brackets do with their contained blocks" and ignore indentation conventions; we use them because presenting things with consistent structure makes it easier for people to chunk the information and process it effectively. Imagine that you have two code bases, which are precisely identical, except that in one of them, this idiom is used consistently wherever it applies, and in the other, the first code base has been copied, and then half of the comparisons have had their operands flipped (and the operator changed if needed). Now have a large number of people try to find a number of difficult bugs in them. I would bet you that you would notice a measurable performance cost to the reliability and speed of debugging from losing the idiom, especially if the tests were significant to the bugs. It's only a few cycles here and there, or one slot of short term memory, but sometimes that's what makes the difference between catching something and not catching it. -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: Seebs on 5 Mar 2010 13:21 On 2010-03-05, Ersek, Laszlo <lacos(a)ludens.elte.hu> wrote: > ... It's either me, or now two of you not noticing (or ignoring) that > "10 == i" satisfies the second but not the first. I often introduce fencepost errors when I swap relationships. No idea why. It's the same as my mysterious inability to learn to reliably add single-digit numbers. (I can do it about 95% of the time, give or take.) > 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. That's pretty much it. -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: Seebs on 5 Mar 2010 13:24
On 2010-03-05, Ersek, Laszlo <lacos(a)ludens.elte.hu> wrote: > Yes, I thought (and think) that that was not unpossible. If my memory > serves, both Keith and Seebs have pointed out that they need to reorder > reverse-ordered relational operators in their heads (sorry if I'm making > this up now) or that it causes extra mental load or something to that > effect. So the typo may be related to the reversing process. It probably is. Actually, that's clarified it. Here's the thing. (x < 10) !(x >= 10) That kind of reversal requires adding/removing an =. So if I'm flipping a comparison relationship, I'm likely to add/remove an =. It turns out that merely changing the direction isn't the same thing as flipping. (x < 10) (10 > x) !(x >= 10) !(10 <= x) .... Yup. I got the >< in the second pair wrong on the first try, had to go back and think about them. I can do one flip or the other, usually, but if two of them are on offer, I tend to screw them up. -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! |