Bad taste in programming [LWN.net]

Bad taste in programming

Posted Mar 1, 2007 18:45 UTC (Thu) by vmole (guest, #111)
In reply to: Bad taste in programming by pr1268
Parent article: Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2

Your first three examples are not bad taste, but simply errors (well, 'for(;;;)' does have its occasional use, but in general...).

OTOH, regarding, the un-readable condition clause: there was a recent thread in lkml about this. Yes, it might be technically correct, but its undereadable and unverifiable to the casual reader. Much better to break up into shorter, independent check. So sayeth Torvalds. Sorry, don't have an exact pointer to the thread.

(Log in to post comments)

Bad taste in programming

Posted Mar 2, 2007 18:48 UTC (Fri) by wcooley (guest, #1233) [Link]

Sure, but the code in question wasn't "for(;;)"--it was "for(;;);"--a subtle but huge difference.

Infinite loops as bad taste

Posted Mar 3, 2007 1:20 UTC (Sat) by pr1268 (subscriber, #24648) [Link]

Actually, I was taught that for(;;) is faster than while(1) since the former doesn't need to perform a logical evaluation, but the latter does. (Wouldn't this be a weird flame war debate?) I'm since convinced that this is old news, since my experiences hacking some C/C++ code with gcc -S and gcc -c show identical .s and .o files in either case (optimized or not).

I recently coded a loop as for(;;i++) { /* ... */ } (don't ask). :^)

Infinite loops as bad taste

Posted Mar 5, 2007 6:15 UTC (Mon) by landley (guest, #6789) [Link]

> Actually, I was taught that for(;;) is faster than while(1)

And circa 1984, this was true.

Compilers change. Optimizers change. Hardware changes drastically. (2
megabytes of L2 cache?)

x=5;
if (blah) x=7;

This is now generally faster than:
if (blah) x=7;
else x=5;

Why? Branch prediction with conditional assignments to avoid bubbles in
the pipeline. Taking a branch is noticeably slower than doing an extra
(unnecessary) assignment, and the if/else means _either_ way you branch.

However, 90% of the time you don't have to _care_ because your compiler
knows about conditional assignment and will rewrite variant #2 to look
like variant #1.

And if you religiously write #1 it's possible that in 5 years new hardware
will show up that makes the _previous_ way of doing it the fast way again.
(Once upon a time, rotating a point around a circle, programmers
precalculated a lookup table of all 360 positions to avoid doing slow
trigonometry math. Then processors got a clock multiplier faster than the
motherboard, and the lookup table became slower than doing the math
because it didn't fit in cache. Then caches got big again, and the lookup
table fit in memory again... It's a pendulum. There IS no one right
answer. Even if you know _everything_ the compiler is doing, if your code
is any good it could easily outlive that specific processor and compiler
version. (And if it isn't any good, what's the point in trying to
optimize it?)

Remember Ken Thompson's "When it doubt, use brute force" because it's darn
good advice.

That said, I use for(;;) because I think it's cleaner. (It lies to the
compiler slightly less; while(1) smells like if(1), and even though both
tests get optimized out I don't like having it there without a reason.)