C elements of style

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(;;)
2)  use of const is preferred over #define
3)  unless extreme efficiency is warranted, use printf instead of putc
& puts


now my question is

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

OR
To what extent these rules are true..???

On Apr 2, 12:26=A0pm, aark...@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) =A0while(1) is preferred over for(;;)
I am opposite here.  The constructs create identical results and the
meaning for both is obvious.  Some lints and compilers will whine
about while (1) but they do not add any noise for for(;;).

> 2) =A0use of const is preferred over #define
This one is obvious.  #define can unexpectedly change something if you
are not careful.

> 3) =A0unless extreme efficiency is warranted, use printf instead of putc
> & puts
Nonsense.  If there is no format string, use puts().  If you are
outputting a single character, use putc().

> now my question is
>
> can anyone give examples for the justification of above rules ..????
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OR
> To what extent these rules are true..???

I like number 2, and the other two rub me the wrong way.

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(;;)
> 2)  use of const is preferred over #define
> 3)  unless extreme efficiency is warranted, use printf instead of putc
> & puts
>
>
> now my question is
>
> can anyone give examples for the justification of above rules ..????
>
>                                OR
> To what extent these rules are true..???

(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."

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

(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?

--
Eric.Sosman@sun.com

In article <0fa3a399-e99a-4b6f-a220-ca49bb9b20e8@m36g2000hse.googlegroups.co
m>,
 
>I am opposite here.  The constructs create identical results and the
>meaning for both is obvious.

An experienced C programmer will of course be familiar with both, but
I don't think the meaning of "for(;;)" is obvious.  It doesn't follow
from anything else that an empty continuation condition is true; the
best you can do is say that it would be pointless if it worked the
other way.  "while(1)" on the other hand is not a special case at all.

-- Richard


--
:wq

On Apr 3, 12:58=A0am, Eric Sosman <Eric.Sos...@sun.com> wrote:

>
=A0Does this Rulemaker go on to
> recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?
>

he gives many rules, some of them are as follows

4) always split a for statement into 3 lines

5) when splitting up a conditional clause(?:),write it on three lines:
the condition line,the true-value line, and the false-value
line.indent the last two lines an extra level

6)allow no more than 5 parameters to a function

7)avoid do/while use while and break instead.

8)use the comma operator inside a for statement only to put together
two statements. never use it to combine three statements

9)always put a break at the end of the last case in a switch statement

user923005 <dcorbit@connx.com> writes:

> On Apr 2, 12:26_pm, aark...@gmail.com wrote: 
> Nonsense.  If there is no format string,
...and the string to print ends in new-line, then...
> use puts().  If you are
> outputting a single character, use putc().

--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b
[]
 ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da
6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},
*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}
}}

In article <1207166230.803380@news1nwk>,
Eric Sosman  <Eric.Sosman@sun.com> wrote:
>aarklon@gmail.com wrote:
 
 

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

My -speculation- would be that the reasoning is that for text
output, printf() appears so often that when putc() or puts()
appears, people may have to stop and think about whether there
is anything "special" or "magic" about what is being output
or about the way that putc() or puts() operate so as to warrant
the use of those functions instead of printf().

For example, I see puts() seldom enough that I tend to forget that
puts() adds \n automatically and then when I glance at code
that uses puts() I tend to think, "Hold on, where's the \n ??"
So there is some "magic" about puts() that has to be remembered.
(especially as fputs() does not add a \n ).

putc(), though, I personally find immediately obvious.
--
"To the modern spirt nothing is, or can be rightly known,
except relatively and under conditions."    -- Walter Pater

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(;;)

This will lead to warnings in some cases. That being said, it's my
preferred way.

> 2)  use of const is preferred over #define

That won't work for array dimensions. There should at least be
exceptions for that case.

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

I can't see why this would be preferable. Besides being possibly less
efficient, printf() is often less readable and more prone to error.

OR
> To what extent these rules are true..???

Style rules can't be true or false.




Brian

aarklon@gmail.com wrote, On 02/04/08 21:15:
> On Apr 3, 12:58 am, Eric Sosman <Eric.Sos...@sun.com> wrote:
>
>  Does this Rulemaker go on to 
>
>  he gives many rules, some of them are as follows
>
> 4) always split a for statement into 3 lines

As an "always" I definitely disagree. In the simple case of something like:
for (i=0; i<lim; i++)
it is completely pointless in my opinion. On some longer or more complex
instances it can make sense to split it.

> 5) when splitting up a conditional clause(?:),write it on three lines:
> the condition line,the true-value line, and the false-value
> line.indent the last two lines an extra level

Again, a stupid rule in my opinion. Think what it would do to...
fprintf(fp,"stuff %d more stuff",ptr?*ptr:0);
Then imagine you have more parameters before and after that one.
I come across requirements most easily implemented like this when
producing interfacing files to be sent to other systems.

> 6)allow no more than 5 parameters to a function

A bit arbitrary and people will certainly argue about precisely what the
limit should be, but makes more sense.

> 7)avoid do/while use while and break instead.

This is just plain stupid. If the problems maps properly on to a
do/while loop then use that rather than trying to bend some other
construct to your needs. I don't use them very often, but when they are
the correct construct they are the correct construct.

> 8)use the comma operator inside a for statement only to put together
> two statements. never use it to combine three statements

Again, rather arbitrary, people will definitely argue over what the
limit should be.

> 9)always put a break at the end of the last case in a switch statement

At last one that I can completely agree with.


Once again, I recommend not using this set of rules.
--
Flash Gordon

aarklon@gmail.com said:

> 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(;;)

Balderdash. Preferred by him, possibly, but not by me. In the vanishingly
rare circumstances where an infinite loop is appropriate, for(;;)
expresses the intent without inducing some implementations to have a giddy
fit over a constant conditional expression.

> 2)  use of const is preferred over #define

Balderdash. Try it and see.

const int MAX = 10;
main()
{
int class[MAX] = {0};
}

The above code is carefully designed to break everywhere! But the reason it
breaks differs depending on what language you're using. In C++, it's okay
for an array size to be specified using a const (but you can't use class
as an object name). In C99, it's okay to specify a variable-length array's
size using a const (but the code breaks because implicit int has gone).
But in C90, the code breaks because you can't use const to specify array
sizes, which are a large part of what #defines are used for (and most of
the other uses for #define are better dealt with by enum than by const).

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

Balderdash. Use whichever is most appropriate.

> now my question is
>
> can anyone give examples for the justification of above rules ..????

It's very unlikely. They seem unjustifiable.

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