Advice from The C++ Programming Language

Chapter 1
1.        When you program, you create a concrete representation of the ideas in your solution to some problem. Let the structure of the program reflect those ideas as directly as possible:
  A.        If you can think of “it” as a separate idea, make it a class.
  B.        If you can think of “it” as a separate entity, make it an object of some class.
  C.        If two classes have a common interface, make that interface an abstract class.
  D.        If the implementations of two classes have something significant in common, make that commonality a base class.
  E.        If a class is a container of objects, make it a template
  F.        If a function implements an algorithm for a container, make it a template function implementing the algorithm for a family of containers
  G.        If a set of classes, templates, etc., are logically related, place them in a common namespace.
2.        When you define either a class that does not implement either a mathematical entity like a matrix or a complex number or a low-level type such as a linked list:
  A.        Don’t use global data (use members).
  B.        Don’t use global functions.
  C.        Don’t use public data members.
  D.        Don’t use friends, except to avoid [a] or [c]
  E.        Don’t put a “type field” in a class; use virtual functions.
  F.        Don’t use inline functions, except as a significant optimization.

Chapter 2
1.        Don’t panic! All will become clear in time
2.        You don’t have to know every detail of C++ to write good programs
3.        Focus on programming techniques, not on language features

Chapter 3
1.        Don’t reinvent the wheel; use libraries.
2.        Don’t believe in magic; understand what your libraries do, how they do it, and at what cost they do it.
3.        When you have a choice, prefer the standard library to other libraries.
4.        Do not think that the standard library is ideal for everything.
5.        Remember to #include the headers for the facilities you use.
6.        Remember that standard library facilities are defined in namespace std
7.        Use string rather than char *
8.        If in doubt use a range-checked vector
9.        Prefer vector<T>, list<T>, and map<key, value> to T[]
10.        When adding elements to a container, use push_back() or back_inserter()
11.        Use push_back() on a vector rather than realloc() on an array
12.        Catch common exceptions in main()

Chapter 4
1.        Keep scopes small
2.        Don’t use the same name in both a scope and an enclosing scope
3.        Declare one name (only) per declaration
4.        Keep common and local names short, and keep uncommon and nonlocal names longer
5.        Avoid similar-looking names
6.        Maintain a consistent naming style
7.        Choose names carefully to reflect meaning rather than implementation
8.        Use a typedef to define a meaningful name for a built-in type in cases in which the built-in type used to represent a value might change
9.        Use typedefs to define synonyms for types; use enumerations and classes to define new types
10.        Remember that every declaration must specify a type (there is no “implicit int”)
11.        Avoid unnecessary assumptions about the numeric value of characters
12.        Avoid unnecessary assumptions about the size of integers
13.        Avoid unnecessary assumptions about the range of floating-point types
14.        Prefer a plain int over a short int or a long int
15.        Prefer a double over a float or a long double
16.        Avoid making unnecessary assumptions about the sizes of objects
17.        Avoid unsigned arithmetic
18.        View signed to unsigned and unsigned to signed conversions with suspicion
19.        View floating-point to integer conversions with suspicion
20.        View conversions to a smaller type, such as int to char, with suspicion

Chapter 5
1.        Avoid nontrivial pointer arithmetic
2.        Take care not to write beyond the bounds of an array
3.        Use 0 rather than NULL
4.        Use vector and valarray rather than built-in (C-style) arrays
5.        Use string rather than zero-terminated arrays of char
6.        Minimize use of plain reference arguments
7.        Avoid void* except in low-level code
8.        Avoid nontrivial literals (“magic numbers”)in code. Instead, define and use symbolic constants

Chapter 6
1.        Prefer the standard library to other libraries and to “handcrafted code;”
2.        avoid complicated expressions;
3.        If in doubt about operator precedence, parenthesize
4.        Avoid explicit type conversion (casts)
5.        When explicit type conversion is necessary, prefer the more specific cast operators to the C-style cast
6.        Use the T(e) notation exclusively for well-defined construction
7.        Avoid expressions with undefined order of evaluation
8.        Avoid goto
9.        Avoid do-statements
10.        Don’t declare a variable until you have a value to initialize it with
11.        Keep comments crisp
12.        Maintain a consistent indentation style
13.        Prefer defining a member operation new() to replacing the global operator new()
14.        When reading input, always consider ill-formed input

Chapter 7
1.        Be suspicious of non-const reference arguments; if you want the function to modify its arguments, use pointers and value return instead
2.        Use const reference arguments when you need to minimize copying of arguments
3.        Use const extensively and consistently
4.        Avoid macros
5.        Avoid unspecified numbers of arguments
6.        Don’t return pointers or references to local variables
7.        Use overloading when functions perform conceptually the same task on different types
8.        When overloading on integers, provide functions to eliminate common ambiguities
9.        When considering the use of a pointer to function, consider whether a virtual function or a template would be a better alternative
10.        If you must use macros, use ugly names with lots of capital letters

Chapter 8
1.        Use namespaces to express logical structure
2.        Place every nonlocal name, except main(), in some namespace
3.        Design a namespace so that you can conveniently use it without accidentally gaining access to unrelated namespaces
4.        Avoid very short names for namespaces
5.        If necessary, use namespace aliases to abbreviate long namespace names
6.        Avoid placing heavy notational burden of users of your namespaces
7.        Use the Namespace::member notation when defining namespace members
8.        Use using namespace only for transition or within a local scope
9.        Use exceptions to decouple the treatment of “errors” from the code dealing with the ordinary processing
10.        Use user-defined rather than built-in types as exceptions
11.        Don’t use exceptions when local control structures are sufficient

Chapter 9
1.        Use header files to represent interfaces and to emphasize logical structure
2.        #include a header in the source file that implements its functions
3.        Don’t define global entities with the same name and similar-but-different meanings in different translation units
4.        Avoid non-inline function definitions in headers
5.        Use #include only at global scope and in namespaces
6.        #include only complete declarations
7.        Use include guards
8.        #include C headers in namespaces to avoid global names
9.        Make headers self-contained
10.        Distinguish between users’ interfaces and implementers’ interfaces
11.        Distinguish between average users’ interfaces and expert users’ interfaces
12.        Avoid nonlocal objects that require run-time initialization in code intended for use as part of non-C++ programs

Chapter 10
1.        Represent concepts as classes
2.        Use public data (structs) only when it really is just data and no invariant is meaningful for the data members
3.        A concrete type is the simplest kind of class. Where applicable, prefer a concrete type over more complicated classes and over plain data structures
4.        Make a function a member only if it needs direct access to the representation of a class
5.        Use a namespace to make the association between a class and its helper functions explicit
6.        Make a member function that doesn’t modify the value of its object a const member function
7.        Make a function that needs access to the representation of a class but needn’t be called for a specific object a static member function
8.        Use a constructor to establish an invariant for a class
9.        If a constructor acquires a resource, its class needs a destructor to release the resource
10.        If a class has a pointer member, it needs copy operations (copy constructor and copy assignment)
11.        If a class has a reference member, it probably needs copy operations (copy constructor and copy assignment)
12.        If a class needs a copy operation or a destructor, it probably needs a constructor, a destructor, a copy assignment, and a copy constructor
13.        Check for self-assignment in copy assignments
14.        When writing a copy constructor, be careful to copy every element that needs to be copied (beware of default initializers)
15.        When adding a new member to a class, always check to see if there are user-defined constructors that need to be updated to initialize the member
16.        Use enumerators when you need to define integer constants in class declarations
17.        Avoid order dependencies when constructing global and namespace objects
18.        Use first-time switches to minimize order dependencies
19.        Remember that temporary objects are destroyed at the end of the full expression in which they are created

Chapter 11
1.        Define operators primarily to mimic conventional usage
2.        For large operands, use const reference argument types
3.        For large results, consider optimizing the return
4.        Prefer the default copy operations if appropriate for a class
5.        Redefine or prohibit copying if the default is not appropriate for a type
6.        Prefer member functions over nonmembers for operations that need access to the representation
7.        Prefer nonmember functions over members for operations that do not need access to the representation
8.        Use namespaces to associate helper functions with “their” class
9.        Use nonmember functions for symmetric operators
10.        Use () for subscripting multidimensional arrays
11.        Make constructors that take a single “size argument” explicit
12.        For non-specialized uses, prefer the standard string (Chapter 20)to the result of your own exercises
13.        Be cautious about introducing implicit conversions
14.        Use member functions to express operators that require an lvalue as its left-hand operand

Chapter 12
1.        Avoid type fields
2.        Use pointers and references to avoid slicing
3.        Use abstract classes to focus design on the provision of clean interfaces
4.        Use abstract classes to minimize interfaces
5.        Use abstract classes to keep implementation details out of interfaces
6.        Use virtual functions to allow new implementations to be added without affecting user code
7.        Use abstract classes to minimize recompilation of user code
8.        Use abstract classes to allow alternative implementations to coexist
9.        A class with a virtual function should have a virtual destructor
10.        An abstract class typically doesn’t need a constructor
11.        Keep the representations of distinct concepts distinct

Chapter 13
1.        Use templates to express algorithms that apply to many argument types
2.        Use templates to express containers
3.        Provide specializations for containers of pointers to minimize code size
4.        Always declare the general form of a template before specializations
5.        Declare a specialization before its use
6.        Minimize a template definition’s dependence on its instantiation contexts
7.        Define every specialization you declare
8.        Consider if a template needs specializations for C-style strings and arrays
9.        Parameterize with a policy object
10.        Use specialization and overloading to provide a single interface to implementations of the same concept for different types
11.        Provide a simple interface for simple cases and use overloading and default arguments to express less common cases
12.        Debug concrete examples before generalizing to a template
13.        Remember to export template definitions that need to be accessible from other translation units
14.        Separately compile large templates and templates with nontrivial context dependencies
15.        Use templates to express conversions but define those conversions very carefully
16.        Where necessary, constrain template arguments using a constraint() member function
17.        Use explicit instantiation to minimize compile time and link time
18.        Prefer a template over derived classes when run-time efficiency is at a premium
19.        Prefer derived classes over a template if adding new variants without recompilations is important
20.        Prefer a template over derived classes when no common base can be defined
21.        Prefer a template over derived classes when built-in types and structures with compatibility constraints are important