Michael Ellerman takes issue with my example of bad coding practice. It would seem that we both ultimately agree that indenting code is no guarantee for it to do what you want - except in Python. Because his example, to wit:
if (x > y) exch(x, y); if (x) printf("hello!"); else x = 0;Is another example of coders assuming that indenting is doing what they mean. This code, according to Kernighan and Richie on page 56, will be compiled to mean:
if (x > y) { exch(x, y); } if (x) { printf("hello!"); } else { x = 0; }Which, though it will compile correctly and will not break if
exch()
is not a #define do { } while (0);
macro,
is not, I'll wager, what Michael has meant by his example (which is, I
believe, that the else clause attaches to the first if). So I'm going
to take his example as another proof of the worth of using braces even if
you think you'll only ever have one line of code in the 'then' case.The other point which I left implicit in my post but Michael has pointed out is that compilation failure in this situation is caused by bad coding practice that is not necessarily related to the line you just added. If the code was:
if (x > y) exch(x,y); else exch(y,z);And I was trying to add the line
exch(z,x);
after
exch(x,y);
, then my addition has suddenly caused compilation
to fail. But my statement is perfectly legitimate, and spending time
looking at the macro of exch()
isn't going to elucidate the
problem. The problem is that the whole structure is going to assume that
the then and else clauses are a single statement; using the
do { } while (0);
hack doesn't solve this - it
doesn't make the bad coding style good. If the if clause is complex, or
the lines are more verbose, or the maintenance programmer isn't a
language lawyer or is just simply lazy, then they may hit the compilation
error and dike their code out to a separate line:
if (x > y) exch(x,y); else exch(y,z); if (x > y) exch(z,x);Which suddenly means a lot more hassle when the tested expression changes or exch changes meaning or the new value of y is suddenly less than x (because it was exchanged with z in the else clause, before). No Good Will Come Of It.
Maybe I should download the kernel source, remove some of these
do { } while (0);
hacks, fix up the relevant
usages so they're properly braced (heh), and make myself an instant
top ten kernel patch submitter... :-)
Last updated: | path: tech / c | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.
Main index
/ tbfw/
- © 2004-2023
Paul Wayper
Valid HTML5