C elements of style

[aarklon@gmail.com]

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

[user923005]

Re: C elements of style

On Apr 2, 12:26 pm, aark...@gmail.c om 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(;;)

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)  use of const is preferred over #define

This one is obvious. #define can unexpectedly change something if you
are not careful.

3)  unless 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 ..????
>
                               OR
To what extent these rules are true..???

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

[Eric Sosman]

Re: C elements of style

aarklon@gmail.c om 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 "adverbAlwa ys
verbUse adjectiveHungar ian 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

[Richard Tobin]

Re: C elements of style

In article <0fa3a399-e99a-4b6f-a220-ca49bb9b20e8@m3 6g2000hse.googl egroups.com>,

>1)  while(1) is preferred over for(;;)

>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

[aarklon@gmail.com]

Re: C elements of style

On Apr 3, 12:58 am, Eric Sosman <Eric.Sos...@su n.comwrote:

>

 Does 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(?:),writ e 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

[Ben Pfaff]

Re: C elements of style

user923005 <dcorbit@connx. comwrites:

On Apr 2, 12:26 pm, aark...@gmail.c om wrote:

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

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);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,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)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Walter Roberson]

Re: C elements of style

In article <1207166230.803 380@news1nwk>,
Eric Sosman <Eric.Sosman@su n.comwrote:

>aarklon@gmail. com wrote:

>I was going through the book "C Elements of style" by steve oualline.

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

(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

[Default User]

Re: C elements of style

aarklon@gmail.c om 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

[Flash Gordon]

Re: C elements of style

Eric Sosman wrote, On 02/04/08 20:58:

aarklon@gmail.c om 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 "adverbAlwa ys
verbUse adjectiveHungar ian 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]

Re: C elements of style

aarklon@gmail.c om wrote, On 02/04/08 21:15:

On Apr 3, 12:58 am, Eric Sosman <Eric.Sos...@su n.comwrote:
>
Does 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

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(?:),writ e 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,"stu ff %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

[Mark McIntyre]

Re: C elements of style

aarklon@gmail.c om 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.

[Richard Heathfield]

Re: C elements of style

Mark McIntyre said:

aarklon@gmail.c om 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.

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.

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

I'd have thought a decent library would be more relevant here. :-)

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

>
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

[Keith Thompson]

Re: C elements of style

"Default User" <defaultuserbr@ yahoo.comwrites :

aarklon@gmail.c om wrote:

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

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.

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

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_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: C elements of style

Richard Heathfield <rjh@see.sig.in validwrites:

Mark McIntyre said:

>aarklon@gmail.c om wrote:

[...]

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

>>
>again identical if you have a decent compiler.

>
I'd have thought a decent library would be more relevant here. :-)

Quibble:

No, it's the compiler that's relevant. A library implementation of
printf can't avoid parsing the format string, even if it optimizes the
case where there are no '%' characters. A compiler, on the other
hand, can sometimes convert a printf call to an equivalent puts call.

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

[Himanshu Chauhan]

Re: C elements of style

aarklon@gmail.c om 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

One benefit of using (2) I can see is, while debugging you can see the
symbol rather than a value.

--Himanshu