faqcataae2.html

this is a mirrored site c-faq. thought might need offline

(and <TT>lint</TT>)
will warn about discarded return values,
an explicit cast to <TT>(void)</TT> is a way of saying
``Yes,
I've decided to ignore the return value from this call,
but please continue to warn me about other
(perhaps inadvertently)
ignored return values.''
It's also common to use
<TT>void</TT> casts
on calls to <TT>strcpy</TT> and <TT>strcat</TT>,
since the return value is

never surprising.
</p>



<p>References:

K&amp;R2 Sec. A6.7 p. 199
<br>
Rationale Sec. 3.3.4
<br>
H&amp;S Sec. 6.2.9 p. 172, Sec. 7.13 pp. 229-30
<hr><hr><hr>
<a name="nullor0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/nullor0.html"><!-- qtag -->Question 17.6</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
If <TT>NULL</TT> and <TT>0</TT> are equivalent
as null pointer constants,
which should I use?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat1f1a.html?sec=null#nullor0">5.9</a>.
<hr><hr><hr>
<a name="bool">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/bool.html"><!-- qtag -->Question 17.7</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Should I use symbolic names like <TT>TRUE</TT>
and <TT>FALSE</TT> for Boolean constants,
or plain 1 and 0?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcate034.html?sec=bool#macros">9.4</a>.
<hr><hr><hr>
<a name="hungarian">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/hungarian.html"><!-- qtag -->Question 17.8</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What is ``Hungarian Notation''?
Is it worthwhile?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Hungarian Notation is
a naming convention,
invented by Charles Simonyi,
which encodes
information about
a variable's
type
(and perhaps its intended use)
in its name.
It is well-loved in some circles and
roundly
castigated in others.
Its chief advantage
is that it makes a variable's type
or intended use
obvious from its name;
its chief disadvantage
is that type information is not necessarily
a worthwhile thing to carry around in the name of a variable.

</p><p>References:

Simonyi and Heller, ``The Hungarian Revolution''

<hr><hr><hr>
<a name="guides">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/guides.html"><!-- qtag -->Question 17.9</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Where can I get the
``Indian Hill Style Guide''
and other
coding standards?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Various documents are available for anonymous ftp from:

<br>
<br>
<pre>
	Site:			File or directory:

	ftp.cs.washington.edu	pub/cstyle.tar.Z
			(the updated Indian Hill guide)

	ftp.cs.toronto.edu	doc/programming
				(including Henry Spencer's
				``10 Commandments for C Programmers'')

	ftp.cs.umd.edu		pub/style-guide
</pre>
</p><p>You may also be interested in the books
<I>The Elements of Programming Style</I>,
<I>Plum Hall Programming Guidelines</I>,
and
<I>C Style: Standards and Guidelines</I>;
see the Bibliography.
</p><p>See also question <a href="faqcatccbd.html?sec=resources#tutorials">18.9</a>.
<hr><hr><hr>
<a name="stylewars">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/stylewars.html"><!-- qtag -->Question 17.10</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Some people say that <TT>goto</TT>'s are evil
and that I should never use them.
Isn't that a bit extreme?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Programming style,
like writing style,
is
somewhat of
an art
and
cannot
be codified by inflexible rules,
although discussions about style often seem to center 
exclusively around such rules.
</p><p>In the case of the <TT>goto</TT> statement,
it
has long been observed
that unfettered use
of <TT>goto</TT>'s
quickly leads to unmaintainable spaghetti code.
However, a simple, unthinking ban on the <TT>goto</TT> statement 
does not necessarily lead immediately to beautiful programming:
an unstructured programmer is just as capable of constructing a 
Byzantine tangle without using any <TT>goto</TT>'s
(perhaps substituting oddly-nested loops and
Boolean
control 
variables, instead).
Many
programmers adopt a moderate stance:
<TT>goto</TT>'s are usually to be avoided,
but are acceptable in a few well-constrained situations,
if necessary:
as multi-level <TT>break</TT> statements,
to coalesce common actions
inside a <TT>switch</TT> statement,
or to centralize cleanup tasks
in a function with several error returns.
</p><p>Most observations or ``rules''
about programming style
(Structured Programming is Good,
<TT>goto</TT>'s are Bad,
functions should fit on one page,
etc.)
usually work better as guidelines than rules,
and work much better
if programmers understand what
the guidelines are trying to accomplish.
Blindly avoiding certain constructs
or following rules without understanding them
can lead to just as many problems
as the rules were supposed to avert.

</p><p>Furthermore, many opinions on programming style are just that: 
opinions.
They may be strongly argued and strongly felt, they may be 
backed up by solid-seeming evidence and arguments,
but the opposing opinions may be just as strongly
felt, supported, and argued.
It's usually futile to get dragged into ``style wars,'' because
on certain issues
(such as those referred to in questions
<a href="faqcat1f1a.html?sec=null#ptrtest">5.3</a>,
<a href="faqcat1f1a.html?sec=null#nullor0">5.9</a>,
<a href="faqcate034.html?sec=bool#macros">9.4</a>,
and
<a href="faqcat204f.html?sec=cpp#nestincl">10.7</a>),
opponents can never
seem to
agree,
or
agree to disagree, or stop arguing.
</p><p>Finally,
as William Strunk has written
(quoted in the Introduction to
Strunk and White's classic <I>Elements of Style</I>),

<blockquote>It is an old observation
that the best writers sometimes disregard the rules of rhetoric.
When they do, however,
the reader will usually find in the sentence
some compensating merit,
attained at the cost of the violation.
Unless he is certain of doing as well,
he will probably do best to follow the rules.
</blockquote></p>




<p>References:

K&amp;R2 Sec. 3.8
<br>
E. Dijkstra, ``Go To Statement Considered Harmful'' 
<br>
D.E. Knuth,
``Structured Programming with goto Statements'' 
<hr><hr><hr>
<a name="vsefficiency">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/vsefficiency.html"><!-- qtag -->Question 17.11</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>

People always say that good style is important,
but when they go out of their way
to use clear techniques
and make their programs readable,
they seem to end up with less efficient programs.
Since efficiency is so important,
isn't it
necessary
to sacrifice some style and
readability?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It's true that grossly inefficient programs are a problem,
but the blind zeal with which many programmers often chase 
efficiency is also a problem.
Cumbersome,
obscure programming tricks not only destroy readability and 
maintainability,
but they may
actually
lead to
slimmer
long-term efficiency 
improvements
than
would more appropriate design or algorithm 
choices.
With care,
it is possible
to
design
code which is
both clean and 
efficient.
</p><p>See also question <a href="faqcat38c2.html?sec=misc#efficiency">20.13</a>.
<hr><hr><hr>
<a name="charstarws2">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../style/charstarws2.html"><!-- qtag -->Question 17.12</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Which is correct,
<pre>
char&nbsp;*p</pre>

or
<pre>
char*&nbsp;p</pre>
?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
In this case,
it's a question of style, not correctness,
but see question <a href="faqcatd3c2.html?sec=decl#charstarws">1.5</a>.
</p><p>Additional links:




<a href="../../style/whitespace.msb.html">further reading</a>
<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcat5e04.html?sec=strangeprob" rev=precedes>prev</a>
<a href="faqcatccbd.html?sec=resources" rel=precedes>next</a>
<a href="faqcat.html" rev=subdocument>up</a>
</p>
<hr>
<p>
<br><!-- lastfooter -->
<a href="../../about.html">about this FAQ list</a>
&nbsp;
<a href="../../eskimo.html">about eskimo</a>
&nbsp;
<a href="../../search.html">search</a>
&nbsp;
<a href="../../feedback.html">feedback</a>
&nbsp;
<a href="../../style/copyright.html">copyright</a>
<p>
Hosted by
<a href="http://www.eskimo.com/"><img src="../../../www.eskimo.com/img/link/eskitiny.gif" alt="Eskimo North"></a>
</body>

<!-- Mirrored from c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=style by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:58:23 GMT -->
</html>