appendixa.html

Thinking in c++ 2nd edition,c++编程思想（第2版）

 <font color=#0000ff>int</font> x;
 <font color=#0000ff>float</font> y;
{
 <font color=#009900>/* body here */</font>
} </PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Here, it would be quite ungainly to put
the opening brace on the same line, so no one did it. However, they did make
various decisions about whether the braces should be indented with the body of
the code or whether they should be at the level of the &#8220;precursor.&#8221;
Thus, we got many different formatting styles. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">There are other arguments for placing the
brace on the line immediately following the declaration (of a class, struct,
function, etc.). The following came from a reader, and is presented here so you
know what the issues are:</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Experienced &#8216;vi&#8217; (vim) users
know that typing the &#8216;]&#8217; key twice will take the user to the next
occurrence of &#8216;{&#8216; (or ^L) in column 0. This feature is extremely
useful in navigating code (jumping to the next function or class definition).
[My comment: when I was initially working under Unix, GNU Emacs was just
appearing and I became enmeshed in that. As a result, &#8216;vi&#8217; has never
made sense to me, and thus I do not think in terms of &#8220;column 0
locations.&#8221; However, there is a fair contingent of &#8216;vi&#8217; users
out there, and they are affected by this issue.]</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Placing the &#8216;{&#8216; on the next
line eliminates some confusing code in complex conditionals, aiding in the
scannability. Example:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>if</font>(cond1
   &amp;&amp; cond2
   &amp;&amp; cond3) {
   statement;
} </PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The above [asserts the reader] has poor
scannability. However,</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>if</font> (cond1
&amp;&amp; cond2
&amp;&amp; cond3)
{
statement;
} </PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">breaks up the &#8216;if&#8217; from the
body, resulting in better readability. [Your opinions on whether this is true
will vary depending on what you&#8217;re used to.]</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Finally, it&#8217;s much easier to
visually align braces when they are aligned in the same column. They visually
"stick out" much better. [End of reader comment]</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The issue of where to put the opening
curly brace is probably the most discordant issue. I&#8217;ve learned to scan
both forms, and in the end it comes down to what you&#8217;ve grown comfortable
with. However, I note that the official Java coding standard (found on
Sun&#8217;s Java Web site) is effectively the same as the one I present here
&#8211; since more folks are beginning to program in both languages, the
consistency between coding styles may be helpful.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The approach I use removes all the
exceptions and special cases, and logically produces a single style of
indentation as well. Even within a function body, the consistency holds, as
in:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>for</font>(<font color=#0000ff>int</font> i = 0; i &lt; 100; i++) {
  cout &lt;&lt; i &lt;&lt; endl;
  cout &lt;&lt; x * i &lt;&lt; endl;
} </PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The style is easy to teach and to
remember &#8211; you use a single, consistent rule for all your formatting, not
one for classes, two for functions (one-line inlines vs. multi-line), and
possibly others for <B>for</B> loops, <B>if</B> statements, etc. The consistency
alone, I think, makes it worthy of consideration. Above all, C++ is a newer
language than C, and although we must make many concessions to C, we
shouldn&#8217;t be carrying too many artifacts with us that cause problems in
the future. Small problems multiplied by many lines of code become big problems.
For a thorough examination of the subject, albeit in C, see <I>C Style:
Standards and Guidelines</I>, by <A NAME="Index2741"></A>David Straker
(Prentice-Hall 1992).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The other constraint I must work under is
the line width, since the book has a limitation of 50 characters. What happens
when something is too long to fit on one line? Well, again I strive to have a
consistent policy for the way lines are broken up, so they can be easily viewed.
As long as something is part of a single definition, argument list, etc.,
continuation lines should be indented one level in from the beginning of that
definition, argument list, etc. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Identifier
names</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Those familiar with Java will notice that
I have switched to using the standard Java style for all identifier names.
However, I cannot be completely consistent here because identifiers in the
Standard C and C++ libraries do not follow this style.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The style is quite straightforward. The
first letter of an identifier is only capitalized if that identifier is a class.
If it is a function or variable, then the first letter is lowercase. The rest of
the identifier consists of one or more words, run together but distinguished by
capitalizing each word. So a class looks like this:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>class</font> FrenchVanilla : <font color=#0000ff>public</font> IceCream {</PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">an object identifier looks like
this:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE>FrenchVanilla myIceCreamCone(3);</PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">and a function looks like
this:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>void</font> eatIceCreamCone();</PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">(for either a member function or a
regular function).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The one exception is for compile-time
constants (<B>const</B> or <B>#define</B>), in which all of the letters in the
identifier are uppercase.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The value of the style is that
capitalization has meaning &#8211; you can see from the first letter whether
you&#8217;re talking about a class or an object/method. This is especially
useful when <B>static</B> class members are accessed.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Order of header
inclusion</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index2742"></A><FONT FACE="Georgia">Headers are
included in order from &#8220;the most specific to the most general.&#8221; That
is, any header files in the local directory are included first, then any of my
own &#8220;tool&#8221; headers, such as
<A NAME="Index2743"></A><B>require.h</B>, then any third-party library headers,
then the Standard C++ Library headers, and finally the C library
headers.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The justification for this comes from
<A NAME="Index2744"></A>John Lakos in <I>Large-Scale C++ Software Design</I>
(Addison-Wesley, 1996):</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><I>Latent usage errors can be avoided by
ensuring that the .h file of a component parses by itself &#8211; without
externally-provided declarations or definitions... Including the .h file as the
very first line of the .c file ensures that no critical piece of information
intrinsic to the physical interface of the component is missing from the .h file
(or, if there is, that you will find out about it as soon as you try to compile
the .c file).</I></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If the order of header inclusion goes
&#8220;from most specific to most general,&#8221; then it&#8217;s more likely
that if your header doesn&#8217;t parse by itself, you&#8217;ll find out about
it sooner and prevent annoyances down the road.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Include guards on header
files</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index2745"></A><A NAME="Index2746"></A><FONT FACE="Georgia"><I>Include
guards </I>are always used inside header files to prevent multiple inclusion of
a header file during the compilation of a single <B>.cpp</B> file. The include
guards are implemented using a preprocessor <B>#define</B> and checking to see
that a name hasn&#8217;t already been defined. The name used for the guard is
based on the name of the header file, with all letters of the file name
uppercase and replacing the &#8216;<B>.</B>&#8217; with an underscore. For
example:</FONT><BR></P></DIV>

<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#009900>// IncludeGuard.h</font>
#ifndef INCLUDEGUARD_H
#define INCLUDEGUARD_H
<font color=#009900>// Body of header file here...</font>
#endif <font color=#009900>// INCLUDEGUARD_H</font></PRE></FONT></BLOCKQUOTE>

<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The identifier on the last line is
included for clarity. Although some preprocessors ignored any characters after
an <A NAME="Index2747"></A><A NAME="Index2748"></A><B>#endif</B>, that
isn&#8217;t standard behavior and so the identifier is commented.
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Use of
namespaces</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In header files, any
&#8220;pollution&#8221; of the
<A NAME="Index2749"></A><A NAME="Index2750"></A>namespace in which the header is
included must be scrupulously avoided. That is, if you change the namespace
outside of a function or class, you will cause that change to occur for any file
that includes your header, resulting in all kinds of problems. No
<A NAME="Index2751"></A><B>using</B> declarations of any kind are allowed
outside of function definitions, and no global <A NAME="Index2752"></A><B>using
</B>directives are allowed in header files.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In <B>cpp</B> files, any global
<B>using</B> directives will only affect that file, and so in this book they are
generally used to produce more easily-readable code, especially in small
programs.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Use of require(&#160;) and
assure(&#160;)</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The
<A NAME="Index2753"></A><B>require(&#160;)</B> and
<A NAME="Index2754"></A><B>assure(&#160;)</B> functions defined in
<A NAME="Index2755"></A><B>require.h</B> are used consistently throughout most
of the book, so that they may properly report problems. If you are familiar with
the concepts of <A NAME="Index2756"></A><I>preconditions </I>and
<A NAME="Index2757"></A><I>postconditions</I> (introduced by Bertrand Meyer) you
will recognize that the use of <B>require(&#160;)</B> and <B>assure(&#160;)</B>
more or less provide preconditions (usually) and postconditions (occasionally).
Thus, at the beginning of a function, before any of the &#8220;core&#8221; of
the function is executed, the preconditions are checked to make sure everything
is proper and that all of the necessary conditions are correct. Then the
&#8220;core&#8221; of the function is executed, and sometimes some
postconditions are checked to make sure that the new state of the data is within
defined parameters. You&#8217;ll notice that the postcondition checks are rare
in this book, and <B>assure(&#160;)</B> is primarily used to make sure that
files were opened successfully.</FONT><BR></P></DIV>
<FONT FACE = "Verdana"><H1 ALIGN="LEFT">
</H1></FONT>

<FONT FACE = "Verdana"><H1 ALIGN="LEFT">
</H1></FONT>
































<FONT FACE = "Verdana"><H1 ALIGN="LEFT">
</H1></FONT>











<HR><DIV ALIGN="LEFT"><P><A NAME="fn64" HREF="#fnB64">[64]</A><FONT FACE="Georgia" SIZE=2>
Ibid.</FONT><BR></P></DIV>

<DIV ALIGN="CENTER">
    <FONT FACE="Verdana" size = "-1">
     [ <a href="Chapter16.html">Previous Chapter</a> ] 
    [ <a href="Contents.html">Table of Contents</a> ] 
    [ <a href="DocIndex.html">Index</a> ]
     [ <a href="AppendixB.html">Next Chapter</a> ] 
    </FONT>
    <BR>
 Last Update:09/27/2001</P></DIV>

</BODY>

</HTML>