Programming 版 (精华区)

发信人: netiscpu (说不如做), 信区: Programming
标  题: C++ 编程准则与忠告 之 Summary of Recommendations
发信站: 紫 丁 香 (Sun Jul 26 11:27:15 1998), 转信



21 Summary of Recommendations

Back to index 

Rec. 1 Optimize code only if you know that you have a performance
problem. Think twice before you begin. 


Rec. 2 If you use a C++ compiler that is based on Cfront, always
compile with the +w flag set to eliminate as many warnings as
possible. 


Rec. 3 An include file should not contain more than one class
definition. 


Rec. 4 Divide up the definitions of member functions or functions
into as many files as possible. 


Rec. 5 Place machine-dependent code in a special file so that it may
be easily located when porting code from one machine to another. 


Rec. 6 Always give a file a name that is unique in as large a context
as possible. 


Rec. 7 An include file for a class should have a file name of the
form + extension. Use uppercase and lowercase letters in the same way
as in the source code. 


Rec. 8 Write some descriptive comments before every function. 


Rec. 9 Use // for comments. 


Rec. 10 Use the directive #include "filename.hh" for user-prepared
include files. 


Rec. 11 Use the directive #include for include files from libraries. 


Rec. 12 Every implementation file should declare a local constant
string that describes the file so the UNIX command what can be used to
obtain information on the file revision. 


Rec. 13 Never include other files in an ".icc" file. 


Rec. 14 Do not use typenames that differ only by the use of uppercase
and lowercase letters. 


Rec. 15 Names should not include abbreviations that are not generally
accepted. 


Rec. 16 A variable with a large scope should have a long name. 


Rec. 17 Choose variable names that suggest the usage. 


Rec. 18 Write code in a way that makes it easy to change the prefix
for global identifiers. 


Rec. 19 Encapsulate global variables and constants, enumerated types,
and typedefs in a class. 


Rec. 20 Always provide the return type of a function explicitly. 


Rec. 21 When declaring functions, the leading parenthesis and the
first argument (if any) are to be written on the same line as the
function name. If space permits, other arguments and the closing
parenthesis may also be written on the same line as the function name.
Otherwise, each additional argument is to be written on a separate
line (with the closing parenthesis directly after the last argument). 


Rec. 22 In a function definition, the return type of the function
should be written on a separate line directly above the function name.


Rec. 23 Always write the left parenthesis directly after a function
name. 


Rec. 24 Braces ("{}") which enclose a block are to be placed in the
same column, on separate lines directly before and after the block. 


Rec. 25 The flow control primitives if, else, while, for and do
should be followed by a block, even if it is an empty block. 


Rec. 26 The dereference operator `*' and the address-of operator `&'
should be directly connected with the type names in declarations and
definitions. 


Rec. 27 Do not use spaces around `.' or `->', nor between unary
operators and operands. 


Rec. 28 Use the c++ mode in GNU Emacs to format code. 


Rec. 29 Access functions are to be inline. 


Rec. 30 Forwarding functions are to be inline. 


Rec. 31 Constructors and destructors must not be inline. 


Rec. 32 Friends of a class should be used to provide additional
functions that are best kept outside of the class. 


Rec. 33 Avoid the use of global objects in constructors and
destructors. 


Rec. 34 An assignment operator ought to return a const reference to
the assigning object. 


Rec. 35 Use operator overloading sparingly and in a uniform manner. 


Rec. 36 When two operators are opposites (such as == and !=), it is
appropriate to define both. 


Rec. 37 Avoid inheritance for parts-of relations. 


Rec. 38 Give derived classes access to class type member data by
declaring protected access functions. 


Rec. 39 Do not attempt to create an instance of a class template
using a type that does not define the member functions which the class
template, according to its documentation, requires. 


Rec. 40 Take care to avoid multiple definition of overloaded
functions in conjunction with the instantiation of a class template. 


Rec. 41 Avoid functions with many arguments. 


Rec. 42 If a function stores a pointer to an object which is accessed
via an argument, let the argument have the type pointer. Use reference
arguments in other cases. 


Rec. 43 Use constant references (const &) instead of call-by-value,
unless using a pre-defined data type or a pointer. 


Rec. 44 When overloading functions, all variations should have the
same semantics (be used for the same purpose). 


Rec. 45 Use inline functions when they are really needed. 


Rec. 46 Minimize the number of temporary objects that are created as
return values from functions or as arguments to functions. 


Rec. 47 Avoid long and complex functions. 


Rec. 48 Pointers to pointers should whenever possible be avoided. 


Rec. 49 Use a typedef to simplify program syntax when declaring
function pointers. 


Rec. 50 The choice of loop construct (for, while or do-while) should
depend on the specific use of the loop. 


Rec. 51 Always use unsigned for variables which cannot reasonably
have negative values. 


Rec. 52 Always use inclusive lower limits and exclusive upper limits.


Rec. 53 Avoid the use of continue. 


Rec. 54 Use break to exit a loop if this avoids the use of flags. 


Rec. 55 Do not write logical expressions of the type if(test) or
if(!test) when test is a pointer. 


Rec. 56 Use parentheses to clarify the order of evaluation for
operators in expressions. 


Rec. 57 Avoid global data if at all possible. 


Rec. 58 Do not allocate memory and expect that someone else will
deallocate it later. 


Rec. 59 Always assign a new value to a pointer that points to
deallocated memory. 


Rec. 60 Make sure that fault handling is done so that the transfer to
exception handling (when this is available in C++) may be easily made.


Rec. 61 Check the fault codes which may be received from library
functions even if these functions seem foolproof. 

--

                              Enjoy Linux!
                          -----It's FREE!-----

※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: mtlab.hit.edu.cn]