LWN.net Logo

Some idle comments about Linus' e-mail response and Linux

Some idle comments about Linus' e-mail response and Linux

Posted Mar 1, 2007 10:40 UTC (Thu) by ekj (guest, #1524)
In reply to: Some idle comments about Linus' e-mail response and Linux by pr1268
Parent article: Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2

Taste is always going to be, to some degree, subjective.

I think the example in the post is a decent example of bad taste:

If you only include a header-file once, it doesn't make any difference if you declare some array there, or in a c-file, the compiler-generated code will be identical anyway.

However, it is *bad-taste* because that isn't what generally belongs in header-files, which makes the code harder to understand for non-insiders, and which increases the risk of errors. Also, it starts being stupid the moment someone else gets the idea of including that header-file, unaware that it contains stuff that header-files do not normally contain.

I'd classify as "bad-taste" programming that is not plainly wrong (as in buggy or as in wasteful), but which nevertheless;

  • Make the code harder to read and/or understand. (illogical organization, poor breakup into function, ill-defined module-boundaries)
  • Increases the chance of subsequent errors. (same as above, confusingly similar variable/function names, unnessecary and unexpected side-effects, lack of handling of corner-cases (even those you know can't *at-the-moment* occur)
  • Is inconsistent. (*which* style is subjective -- once you picked one you should stick with it though.)
  • Just plain looks bad. (the extreme example being unindented code)


(Log in to post comments)

Some idle comments about Linus' e-mail response and Linux

Posted Mar 1, 2007 11:27 UTC (Thu) by k8to (subscriber, #15413) [Link]

There's lots of forms of bad taste. Doing something in a complex sophisticated way when a simplistic straightforward way will get the job done fine is a "favorite" of mine.

But I think in design and engineering, bad taste is not very subjective. I think there is a high degree of consensus among people skilled in those fields about what is in bad taste. Sure there's some subjectivity, but I think it's, in practice, quite small.

Some idle comments about Linus' e-mail response and Linux

Posted Mar 1, 2007 11:33 UTC (Thu) by Randakar (guest, #27808) [Link]

Linus's definition of 'bad taste' is not just limited to aesthetics and structure it seems. Quite often he hammers on deeper things:

- interfaces - does the interface make sense for the problem at hand?
See for instance the recent discussion between him and Ingo on the syslet interface, where Linus hates the interface because it is 'almost usable'. (though in this instance Linus seems to not accuse Ingo of bad taste as such, but merely of overdesigning things for the problem at hand)

- architecture. A good example there would be the suspend-to-ram vs suspend-to-disk discussion, where suspend-to-ram was generally broken because the whole suspend process was ill-defined from a conceptual standpoint, rather than from an aestetic one.

Bad taste in programming

Posted Mar 1, 2007 17:14 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Thanks to the above posters for your responses.... But I was thinking more low-level bad taste in kernel programming. ;-) As in:

  • /* New kernel idle loop */
    for(;;);
  • if(something->uid = 0)
      /* Hopefully no one will notice missing '=' */
  • if(x != x)
      /* How come this code never gets executed? */
  • while(!((!x)&&(y->a!=3))||(y->b<=y->c->d->e())&&z->f())
      /* Someone tell me this while condition is easy to read */
  • ...

But I suppose bad taste can exist at all levels of programming.

Disclaimer: I am easily entertained by browsing code at the IOCCC Web site, but I whole-heartedly agree that it's absolutely no fun having to maintain sloppy code whose author exhibited bad taste.

As for coding style (indentation, proper use of curly braces, etc.), Robert Love's book has some style guidelines for kernel code in one of the appendices. Not that I'm trying to plug his book or anything (but it is a decent read).

Bad taste in programming

Posted Mar 1, 2007 18:45 UTC (Thu) by vmole (guest, #111) [Link]

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.

Bad taste in programming

Posted Mar 2, 2007 16:57 UTC (Fri) by kleptog (subscriber, #1183) [Link]

Actually, I like for(;;) because I find it stands out and looks better than while(1).

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.)

Bad taste in programming

Posted Mar 2, 2007 22:16 UTC (Fri) by maney (subscriber, #12630) [Link]

/* New kernel idle loop */
for(;;);

Aw, man, don't do that - Ballmer's already ranting about his missing IP as it is.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds