📄 appendixb.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:06
Translation Platform:Win32
Number of Output files:22
This File:AppendixB.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>B: Programming Guidelines</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="AppendixA.html">Previous Chapter</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="AppendixC.html">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc472655067"></A><A NAME="Heading486"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
B: Programming Guidelines</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>This appendix is a collection of
suggestions for C++ programming. They’ve been assembled over the course of
my teaching and programming experience and</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">also from the insights of friends
including Dan Saks<A NAME="Index2758"></A> (co-author with Tom
Plum<A NAME="Index2759"></A> of <I>C++ Programming Guidelines</I>, Plum Hall,
1991), Scott Meyers<A NAME="Index2760"></A> (author of <I>Effective C++</I>,
2<SUP>nd</SUP> edition, Addison-Wesley, 1998), and Rob
Murray<A NAME="Index2761"></A> (author of <I>C++ Strategies & Tactics</I>,
Addison-Wesley, 1993). Also, many of the tips are summarized from the pages of
<I>Thinking in C++</I>.
<A NAME="Index2762"></A><A NAME="Index2763"></A><A NAME="Index2764"></A><A NAME="Index2765"></A><A NAME="Index2766"></A></FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">First make it work, then
make it fast. This is true even if you are certain that a piece of code is
really important and that it will be a principal bottleneck in your system.
Don’t do it. Get the system going first with as simple a design as
possible. Then if it isn’t going fast enough, profile it. You’ll
almost always discover that “your” bottleneck isn’t the
problem. Save your time for the really important
stuff.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Elegance
always pays off. It’s not a frivolous pursuit. Not only does it give you a
program that’s easier to build and debug, but it’s also easier to
understand and maintain, and that’s where the financial value lies. This
point can take some experience to believe, because it can seem that while
you’re making a piece of code elegant, you’re not being productive.
The productivity comes when the code seamlessly integrates into your system, and
even more so when the code or system is
modified.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Remember
the “divide and conquer” principle. If the problem you’re
looking at is too confusing, try to imagine what the basic operation of the
program would be, given the existence of a magic “piece” that
handles the hard parts. That “piece” is an object – write the
code that uses the object, then look at the object and encapsulate <I>its</I>
hard parts into other objects,
etc.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Don’t
automatically rewrite all your existing C code in C++ unless you need to
significantly change its functionality (that is, don’t fix it if it
isn’t broken). <I>Recompiling</I> C in C++ is a valuable activity because
it may reveal hidden bugs. However, taking C code that works fine and rewriting
it in C++ may not be the best use of your time, unless the C++ version will
provide a lot of opportunities for reuse as a
class.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">If you do
have a large body of C code that needs changing, first isolate the parts of the
code that will not be modified, possibly wrapping those functions in an
“API class” as static member functions. Then focus on the code that
will be changed, refactoring it into classes to facilitate easy modifications as
your maintenance
proceeds.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Separate
the class creator from the class user (<I>client programmer</I>). The class user
is the “customer” and doesn’t need or want to know
what’s going on behind the scenes of the class. The class creator must be
the expert in class design and write the class so that it can be used by the
most novice programmer possible, yet still work robustly in the application.
Library use will be easy only if it’s
transparent.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">When
you create a class, make your names as clear as possible. Your goal should be to
make the client programmer’s interface conceptually simple. Attempt to
make your names so clear that comments are unnecessary. To this end, use
function overloading and default arguments to create an intuitive, easy-to-use
interface.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Access
control allows you (the class creator) to change as much as possible in the
future without damaging client code in which the class is used. In this light,
keep everything as <B>private</B> as possible, and make only the class interface
<B>public</B>, always using functions rather than data. Make data <B>public</B>
only when forced. If class users don’t need to access a function, make it
<B>private</B>. If a part of your class must be exposed to inheritors as
<B>protected</B>, provide a function interface rather than expose the actual
data. In this way, implementation changes will have minimal impact on derived
classes.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Don’t
fall into analysis paralysis. There are some things that you don’t learn
until you start coding and get some kind of system working. C++ has built-in
firewalls; let them work for you. Your mistakes in a class or set of classes
won’t destroy the integrity of the whole
system.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Your
analysis and design must produce, at minimum, the classes in your system, their
public interfaces, and their relationships to other classes, especially base
classes. If your design methodology produces more than that, ask yourself if all
the pieces produced by that methodology have value over the lifetime of the
program. If they do not, maintaining them will cost you. Members of development
teams tend not to maintain anything that does not contribute to their
productivity; this is a fact of life that many design methods don’t
account for.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Write
the test code first (before you write the class), and keep it with the class.
Automate the running of your tests through a makefile or similar tool. This way,
any changes can be automatically verified by running the test code, and
you’ll immediately discover errors. Because you know that you have the
safety net of your test framework, you will be bolder about making sweeping
changes when you discover the need. Remember that the greatest improvements in
languages come from the built-in testing that type checking, exception handling,
etc., provide, but those features take you only so far. You must go the rest of
the way in creating a robust system by filling in the tests that verify features
that are specific to your class or
program.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Write the
test code first (before you write the class) in order to verify that your class
design is complete. If you can’t write test code, you don’t know
what your class looks like. In addition, the act of writing the test code will
often flush out additional features or constraints that you need in the class
– these features or constraints don’t always appear during analysis
and design.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Remember
a fundamental rule of software
engineering</FONT><A NAME="fnB65" HREF="#fn65">[65]</A><A NAME="Index2767"></A><FONT FACE="Georgia">:
<I>All software design problems can be simplified by introducing an extra level
of conceptual indirection.</I> This one idea is the basis of abstraction, the
primary feature of object-oriented
programming.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Make
classes as atomic as possible; that is, give each class a single, clear purpose.
If your classes or your system design grows too complicated, break complex
classes into simpler ones. The most obvious indicator of this is sheer size: if
a class is big, chances are it’s doing too much and should be broken
up.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Watch for long
member function definitions. A function that is long and complicated is
difficult and expensive to maintain, and is probably trying to do too much all
by itself. If you see such a function, it indicates that, at the least, it
should be broken up into multiple functions. It may also suggest the creation of
a new class.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Watch
for long argument lists. Function calls then become difficult to write, read and
maintain. Instead, try to move the member function to a class where it is (more)
appropriate, and/or pass objects in as
arguments.</FONT><LI><FONT FACE="Verdana"> </FONT><FONT FACE="Georgia">Don’t
repeat yourself. If a piece of code is recurring in many functions in derived
classes, put that code into a single function in the base class and call it from
the derived-class functions. Not only do you save code space, you provide for
easy propagation of changes. You can use an inline function for efficiency.
Sometimes the discovery of this common code will add valuable functionality to
your
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -