Bjarne Stroustrup Quotations 2 (some C + + use note points)

First, to the reader
1.
When you are in the process, you are building a specific representation of your ideas in a solution to a problem. Allow the structure of the program to reflect these ideas as directly as possible:
★. If you can think of "it" as an independent concept, make it into a class.
★. If you can think of "it" as a separate entity, make it an object of a class.
★. If two classes have a common interface, this interface is made into an abstract class.
★. If the implementations of the two classes have something significant in common, make these commonalities into a base class.
★. If a class is a container for an object, make it a template.
★. If a function implements an algorithm for a container, it becomes a template function available to a family of containers.
★. If a group of classes, templates, and so on have a logical connection with each other, put them into a namespace.
2.
When you define a class that does not implement a mathematical object such as a matrix or complex number, or when you define a low-level type such as a linked table:
★. Do not use global data (using members).
★. Do not use global functions.
★. Do not use public data members.
★. Do not use friends unless you want to avoid a or C.
★. Do not put a "type field" in a class (that is, a flag field that is placed to illustrate the data stored by a class)
, using virtual functions.
★. Do not use inline functions (inline function) unless they are optimized as a significant effect.
Ii. Overview of C + +
1.
Don't be afraid, everything will become clearer with the passage of time.
2. You don't need to know all the details of C + + to write a good C + + program.
3.
Please pay particular attention to programming techniques, not to various language features.
III. Overview of the standard library
1. Don't try to do everything as if you were reinventing the wheel, and use the library.
2.
Don't believe in miracles, understand what your library can do, how they do it, and how much it costs to do it.
3. When you encounter a choice, you should prefer the standard library instead of the other libraries.
4.
Don't think the standard library is ideal for anything.
5. Remember the header files that include the features you use.
6.
Remember, the functionality of the standard library is defined in the namespace Std.
7. Please use string instead of char*.
8.
If you suspect, use a vector that checks the range of intervals (for example, VEC).
9. Vector<t>, List<t> and
Map<key,value> are better than t[].
10. If you add an element to a container, use push_back () or
Back_inserter ().
11. The push_back () of the vector is used instead of the realloc () of the array.
12.
Catches a public exception in main ().
Iv. types and declarations
1. Maintain a smaller scope.
2.
Do not use the same name in a scope and its perimeter scope.
3. Only one name is declared in a declaration.
4.
Make commonly used and local names shorter, so that the less common and global names are longer.
5. Avoid names that look similar.
6. Maintain some kind of unified naming style.
7.
Choose names carefully, reflecting their meaning rather than reflecting the way they are implemented.
8. If the internal type used represents a value that may change, use a typedef
Define a meaningful name for it.
9. Define a synonym for a type with a TypeDef, and use an enumeration or class to define the new type.
10.
Remember that each declaration must describe a type (there is no "implicit int").
11. Avoid unnecessary assumptions about character values.
12.
Avoid unnecessary assumptions about the size of integers.
13. Avoid unnecessary assumptions about the range of floating-point types.
14. Prefer to use normal int instead of short int
or a long int.
15. Use double instead of float or long double for precedence.
16. Preferential use of normal char
Instead of signed char or unsigned char.
17. Avoid making unnecessary assumptions about the size of the object.
18.
Avoid unsigned arithmetic.
19. The conversion from signed to unsigned, or from unsigned to signed, should be viewed with doubt.
20.
The conversion from floating point to integral type should be viewed with doubt.
21. The conversion to a smaller type, such as converting int to char, should be viewed with doubt.
V. Advice
1.
Avoid the non-trivial pointer arithmetic.
2. Be careful not to go beyond the bounds of the array to write.
3. Try to use 0 instead of NULL.
4. Use vector as much as possible
And Valarray, not an array of internal (c-style).
5. Try to use a string instead of a char array ending with 0.
6.
Try to use less common reference parameters.
7. Avoid void*, except in some underlying code.
8.
Avoid using non-trivial amounts of text in your code ("mysterious Numbers"). Instead, you should define and use various symbolic constants. (This should be understood to avoid the use of meaningless immediate numbers, but to define constants that represent meaning, for example, with true instead of 1 (c + +) or-1 (VB))

For several reasons, macros have become annoying, disgusting, messy mixes, the main reason is that they are touted as a text replacement facility, the effects of which are produced during the preprocessing phase, when the syntax and semantics of C + + have not yet worked. I hate most forms of pre-processors and macros. One of the goals of C + + is to make the preprocessor of C redundant, because I think its operation is inherently error-prone. The first rule about macros is: don't use it unless you have to. Almost every macro illustrates a flaw in programming languages, programs, or programmers. Http://www.cnblogs.com/lfsblack/p/3274682.html

Bjarne Stroustrup Quotations 2 (some C + + use note points)