C elements of style

Eric Sosman wrote, On 02/04/08 20:58:
> aarklon@gmail.com wrote: 
>
>     (1) is an expression of somebody's personal preference,
> in the form of a rule.  It seems to me to have as much force
> as "indent in multiples of three spaces" or "adverbAlways
> verbUse adjectiveHungarian nounNotation."

Agreed.

>     (2) has appeared in the draft CERT "Secure C Coding
> Standard," and some justification is given there.  For what
> it's worth, I find the justifications unconvincing.  Still,
> of the Three Rules this may be the most defensible.

The problem is that const does not introduce a compile time constant so
it is not suitable for a lot of purposes and can cause confusion in
others. I would say that (ab)using enum to create constants of type int
has value and #define for the rest often makes more sense.

>     (3) seems silly.  It might make sense if inverted ("Don't
> switch from printf() to putchar() just for a tiny speed gain"),
> but in the actual form used ...  Does this Rulemaker go on to
> recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

Agreed.

Based on that sample I would say it was a source not to be trusted.
--
Flash Gordon

"Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
news:sh9dc5xemh.ln2@news.flash-gordon.me.uk...
> aarklon@gmail.com wrote, On 02/04/08 21:15: 
[snip] 
>
> At last one that I can completely agree with.

My addition:

a switch statement *must* contain a default branch, even if it only
contains:

default:
assert(0);
break;

because you know it will never be exercised.



--
Posted via a free Usenet account from http://www.teranews.com

"Dann Corbit" <dcorbit@connx.com> writes:
[coding standards]
> My addition:
>
> a switch statement *must* contain a default branch, even if it only
> contains:
>
>    default:
>       assert(0);
>       break;
>
> because you know it will never be exercised.

I have mixed feelings about this, because it (in my experience)
defeats the ability of the compiler to remind you that you forgot
to add a case for some value of an enumeration type.
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_

In article <47f405e9$0$26022$88260bb3@free.teranews.com>,
Dann Corbit <dcorbit@connx.com> wrote:

>a switch statement *must* contain a default branch, even if it only
>contains:
>
>   default:
>      assert(0);
>      break;
>
>because you know it will never be exercised.

I often do that, but I wouldn't make it an absolute rule.  For
example, if the branches of a switch exhausted all the values of an
enum, and I was confident that the variable only had instances of that
enum assigned to it, I probably wouldn't bother with the default.

Similarly, if an integer variable represented a boolean, I wouldn't
bother to write


if(t == 0)
.. false case ...;
else if(t == 1)
.. true case ...;
else
assert(0);

even though a value of 2 would imply an bug just as much as an
unexpected value in a switch.

-- Richard
--
:wq

aarklon@gmail.com wrote:
> Hi all,
>
> I was going through the book "C Elements of style" by steve oualline.
> in this book many guidelines are given.
>
> the following were seen in the book as rules
>
> 1)  while(1) is preferred over for(;;)

any decent compiler will convert them into exactly the same opcodes.

> 2)  use of const is preferred over #define

Try using a const to define an array size (in C89), or as a case label.

> 3)  unless extreme efficiency is warranted, use printf instead of putc
> & puts

again identical if you have a decent compiler.

> can anyone give examples for the justification of above rules ..????

No, they're stylistic, not practical.

Mark McIntyre said:

> aarklon@gmail.com wrote: 
>
> any decent compiler will convert them into exactly the same opcodes.

True - but that isn't really the point, is it? The point is that you have
two different ways of describing the same thing in the source language,
and Mr Oualline is expressing a preference for one over the other,
presumably because he finds it more readable or more logical or something.
There is nothing wrong with favouring one mode of expression over another
when the two both mean the same thing (i.e. will be converted into exactly
the same opcodes), but one should not normally expect that everybody else
will agree with one's choice or one's reasoning.
 
>
> Try using a const to define an array size (in C89), or as a case label.
> 
>
> again identical if you have a decent compiler.

I'd have thought a decent library would be more relevant here. :-)
 
>
> No, they're stylistic, not practical.

I agree that there doesn't seem to be any practical purpose behind any of
these three recommendations. To call them "rules" is just silly.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <47f405e9$0$26022$88260bb3@free.teranews.com>,
> Dann Corbit <dcorbit@connx.com> wrote: 
>
> I often do that, but I wouldn't make it an absolute rule.  For
> example, if the branches of a switch exhausted all the values of an
> enum, and I was confident that the variable only had instances of that
> enum assigned to it, I probably wouldn't bother with the default.

And, as others have pointed out, adding a "default:" might inhibit a
warning if you leave something out.

> Similarly, if an integer variable represented a boolean, I wouldn't
> bother to write
>
>
>    if(t == 0)
>      ... false case ...;
>    else if(t == 1)
>      ... true case ...;
>    else
>      assert(0);
>
> even though a value of 2 would imply an bug just as much as an
> unexpected value in a switch.

If t represents a boolean value, I wouldn't compare it to either 0 or
1:

if (t) {
.. true case ...
}
else {
.. false case ...
}

(Or use !t and reverse the order if you prefer.)

For that matter, if t really is boolean, then a value of 2 *doesn't*
necessarily imply a bug.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Default User" <defaultuserbr@yahoo.com> writes:
> aarklon@gmail.com wrote: 
>
> This will lead to warnings in some cases. That being said, it's my
> preferred way.
> 
>
> That won't work for array dimensions. There should at least be
> exceptions for that case.

If your compiler supports VLAs, it *will* work for array dimensions.
And that could be a problem.

"const" doesn't create a constant expression.  If you don't need a
constant expression (i.e., one that must be evaluable at compile
time), then by all means use "const"; it's cleaner IMHO than #define.
But if you need a constant expression, "const" just won't do the job.
 
>
> I can't see why this would be preferable. Besides being possibly less
> efficient, printf() is often less readable and more prone to error.

puts() also avoids problems like:

char *message = "Hello, %d world";
printf(message);

But the solution to that is to understand who printf works.

I have no strong preference one way or the other for printf vs. puts
in cases where either will do the job.

[...]

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"