📄 appendixa.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:TIC2Vone.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:09/27/2001
Translation Time:05:26:04
Translation Platform:Win32
Number of Output files:22
This File:AppendixA.html
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>A: Coding Style</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/CPPServices/SolutionGuide.html">Exercise Solutions</a> ]
[ <a href="http://www.mindview.net/ThinkingInCPP2e.html">Volume 2</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/CPPServices/#PublicSeminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CPPServices/#SeminarsOnCD">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in C++, 2nd ed. Volume 1</FONT></H2></FONT>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3></FONT>
<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>
</CENTER>
</P></DIV><A NAME="_Toc472655066"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
A: Coding Style</H1></FONT>
<A NAME="Heading485"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>This appendix is not about
indenting and placement of parentheses and curly braces, although that will be
mentioned. It is about the general guidelines used in
</FONT><BR><FONT FACE="Verdana" SIZE=4>this book for organizing the code
listings.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Although many of these issues have been
introduced throughout the book, this appendix appears at the end so it can be
assumed that every topic is fair game, and if you don’t understand
something you can look it up in the appropriate section.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">All the decisions about coding style in
this book have been deliberately considered and made, sometimes over a period of
years. Of course, everyone has their reasons for organizing code the way they
do, and I’m just trying to tell you how I arrived at mine and the
constraints and environmental factors that brought me to those
decisions.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>General</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In the text of this book, identifiers
(function, variable, and class names) are set in <B>bold</B>. Most keywords will
also be set in bold, except for those keywords that are used so much that the
bolding can become tedious, such as “class” and
“virtual.”</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">I use a particular coding style for the
examples in this book. It was developed over a number of years, and was
partially inspired by Bjarne Stroustrup’s<A NAME="Index2733"></A> style in
his original <I>The C++ Programming
Language</I>.</FONT><A NAME="fnB64" HREF="#fn64">[64]</A><FONT FACE="Georgia">
The subject of formatting style is good for hours of hot debate, so I’ll
just say I’m not trying to dictate correct style via my examples; I have
my own motivation for using the style that I do. Because C++ is a free-form
programming language, you can continue to use whatever style you’re
comfortable with.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">That said, I will note that it is
important to have a consistent formatting style within a project. If you search
the Internet, you will find a number of tools that can be used to reformat all
the code in your project to achieve this valuable consistency.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The programs in this book are files that
are automatically extracted from the text of the book, which allows them to be
tested to ensure that they work correctly. Thus, the code files printed in the
book should all work without compile-time errors when compiled with an
implementation that conforms to Standard C++ (note that not all compilers
support all language features). The errors that <I>should</I> cause compile-time
error messages are commented out with the comment <B>//! </B>so they can be
easily discovered and tested using automatic means. Errors discovered and
reported to the author will appear first in the electronic version of the book
(at <I>www.BruceEckel.com</I>) and later in updates of the
book.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">One of the standards in this book is that
all programs will compile and link without errors (although they will sometimes
cause warnings). To this end, some of the programs, which demonstrate only a
coding example and don’t represent stand-alone programs, will have empty
<B>main( )</B> functions, like this</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>int</font> main() {}</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This allows the linker to complete
without an error. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The standard for <B>main( )</B> is
to return an <B>int</B>, but Standard C++ states that if there is no
<B>return</B> statement inside <B>main( )</B>, the compiler will
automatically generate code to <B>return 0</B>. This option (no <B>return
</B>statement in <B>main( )</B>)<B> </B>will be used in this book (some
compilers may still generate warnings for this, but those are not compliant with
Standard C++).</FONT><A NAME="_Toc312373824"></A><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>File names</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index2734"></A><A NAME="Index2735"></A><FONT FACE="Georgia">In
C, it has been traditional to name header files (containing declarations) with
an extension of <B>.h</B> and implementation files (that cause storage to be
allocated and code to be generated) with an extension of <B>.c</B>. C++ went
through an evolution. It was first developed on Unix, where the operating system
was aware of upper and lower case in file names. The original file names were
simply capitalized versions of the C extensions: <B>.H</B> and <B>.C</B>. This
of course didn’t work for operating systems that didn’t distinguish
upper and lower case, such as DOS. DOS C++ vendors used extensions of <B>hxx</B>
and <B>cxx</B> for header files and implementation files, respectively, or
<B>hpp</B> and <B>cpp</B>. Later, someone figured out that the only reason you
needed a different extension for a file was so the compiler could determine
whether to compile it as a C or C++ file. Because the compiler never compiled
header files directly, only the implementation file extension needed to be
changed. The custom, across virtually all systems, has now become to use
<B>cpp</B> for implementation files and <B>h</B> for header files. Note that
when including Standard C++ header files, the option of having no file name
extension is used, i.e.: <B>#include <iostream></B>.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Begin and end comment
tags</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index2736"></A><A NAME="Index2737"></A><FONT FACE="Georgia">A
very important issue with this book is that all code that you see in the book
must be verified to be correct (with at least one compiler). This is
accomplished by automatically extracting the files from the book. To facilitate
this, all code listings that are meant to be compiled (as opposed to code
fragments, of which there are few) have comment tags at the beginning and end.
These tags are used by the code-extraction tool <B>ExtractCode.cpp</B> in Volume
2 of this book (which you can find on the Web site <I>www.BruceEckel.com</I>) to
pull each code listing out of the plain-ASCII text version of this
book.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The end-listing tag simply tells
<B>ExtractCode.cpp</B> that it’s the end of the listing, but the
begin-listing tag is followed by information about what subdirectory the file
belongs in (generally organized by chapters, so a file that belongs in Chapter 8
would have a tag of <B>C08</B>), followed by a colon and the name of the listing
file.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Because <B>ExtractCode.cpp</B> also
creates a <A NAME="Index2738"></A><B>makefile</B> for each subdirectory,
information about how a program is made and the command-line used to test it is
also incorporated into the listings. If a program is stand-alone (it
doesn’t need to be linked with anything else) it has no extra information.
This is also true for header files. However, if it doesn’t contain a
<B>main( )</B> and is meant to be linked with something else, then it has
an <B>{O}</B> after the file name. If this listing is meant to be the main
program but needs to be linked with other components, there’s a separate
line that begins with <B>//{L}</B> and continues with all the files that need to
be linked (without extensions, since those can vary from platform to
platform).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You can find examples throughout the
book.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If a file should be extracted but the
begin- and end-tags should not be included in the extracted file (for example,
if it’s a file of test data) then the begin-tag is immediately followed by
a ‘<B>!</B>’.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=5><B>Parentheses, braces, and
indentation</B></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You may notice the formatting style in
this book is different from many traditional C styles. Of course, everyone
thinks their own style is the most rational. However, the style used here has a
simple logic behind it, which will be presented here mixed in with ideas on why
some of the other styles developed.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The formatting style is motivated by one
thing: presentation, both in print and in live seminars. You may feel your needs
are different because you don’t make a lot of presentations. However,
working code is read much more than it is written, and so it should be easy for
the reader to perceive. My two most important criteria are
“scannability” (how easy it is for the reader to grasp the meaning
of a single line) and the number of lines that can fit on a page. This latter
may sound funny, but when you are giving a live presentation, it’s very
distracting for the audience if the presenter must shuffle back and forth
between slides, and a few wasted lines can cause this.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Everyone seems to agree that code inside
braces should be indented. What people don’t agree on – and the
place where there’s the most inconsistency within formatting styles
– is this: Where does the opening brace go? This one question, I think, is
what causes such variations among coding styles (For an enumeration of coding
styles, see C++ Programming Guidelines, by <A NAME="Index2739"></A>Tom Plum and
<A NAME="Index2740"></A>Dan Saks, Plum Hall 1991.) I’ll try to convince
you that many of today’s coding styles come from pre-Standard C
constraints (before function prototypes) and are thus inappropriate
now.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">First, my answer to that key question:
the opening brace should always go on the same line as the
“precursor” (by which I mean “whatever the body is about: a
class, function, object definition, if statement, etc.”). This is a
single, consistent rule I apply to all of the code I write, and it makes
formatting much simpler. It makes the “scannability” easier –
when you look at this line:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>int</font> func(<font color=#0000ff>int</font> a);</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">you know, by the semicolon at the end of
the line, that this is a declaration and it goes no further, but when you see
the line:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>int</font> func(<font color=#0000ff>int</font> a) {</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">you immediately know it’s a
definition because the line finishes with an opening brace, not a semicolon. By
using this approach, there’s no difference in where you place the opening
parenthesis for a multi-line definition:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>int</font> func(<font color=#0000ff>int</font> a) {
<font color=#0000ff>int</font> b = a + 1;
<font color=#0000ff>return</font> b * 2;
} </PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">and for a single-line definition that is
often used for inlines:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>int</font> func(<font color=#0000ff>int</font> a) { <font color=#0000ff>return</font> (a + 1) * 2; }</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Similarly, for a class:</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>class</font> Thing;</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">is a class name declaration,
and</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>class</font> Thing {</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">is a class definition. You can tell by
looking at the single line in all cases whether it’s a declaration or
definition. And of course, putting the opening brace on the same line, instead
of a line by itself, allows you to fit more lines on a page. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">So why do we have so many other styles?
In particular, you’ll notice that most people create classes following the
style above (which Stroustrup uses in all editions of his book <I>The C++
Programming Language</I> from Addison-Wesley) but create function definitions by
putting the opening brace on a single line by itself (which also engenders many
different indentation styles). Stroustrup does this except for short inline
functions. With the approach I describe here, everything is consistent –
you name whatever it is (<B>class</B>, function, <B>enum</B>, etc.) and on that
same line you put the opening brace to indicate that the body for this thing is
about to follow. Also, the opening brace is the same for short inlines and
ordinary function definitions.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">I assert that the style of function
definition used by many folks comes from pre-function-prototyping C, in which
you didn’t declare the arguments inside the parentheses, but instead
between the closing parenthesis and the opening curly brace (this shows
C’s assembly-language roots):</FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>void</font> bar()
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -