First, the reader
1. When programming, you are a specific representation in the idea of your solution for a problem. Let the structure of the program directly reflect these ideas as much as possible:
★. If you can see "it" as an independent concept, make it a class.
★. If you can see "it" as a separate entity, do it into an object of a class.
★. If two classes have a common interface, make this interface into an abstract class.
★. If the two classes have some significant common things, they make these commonality into a base class.
★. If a class is a container of an object, make it a template.
★. If a function implements an algorithm for a container, make it a template function available to a group container.
★. If a set of classes, templates, etc., have logical contacts, put them in a name space.
2. When you define a class that doesn't implement a mathematical object such as a matrix or multiplex, or define a low-level type such as a link table:
★ Do not use global data (using members).
★ Do not use global functions.
★ Do not use public data members.
★ Do not use friends unless A or C is avoided.
★. Do not place "Type Domain" in a class (refer to the flag field placed in order to illustrate the data stored in the data; use the virtual function.
★ Do not use online function, unless the effect is significantly optimized.
Second, C overview
1. Don't be afraid, everything will gradually beat over time.
2. You don't need to write a good C program after all the details of C .
3. Please pay special attention to program design technology, not a variety of language characteristics.
Third, standard library overview
1. Don't try to do everything as you reinvent the wheel; go to the library.
2. Don't believe in miracles; understand what your library can do, how do they do, how much cost is needed?
3. When you encounter a choice, you should prefer a standard library instead of other libraries.
4. Don't think that the standard library is ideal for anything.
5. Remember the header file of #include you used.
6. Remember, the functionality of the standard library is defined in the namespace STD.
7. Please use String instead of char *.
8. If doubt, use a vector (for example, VEC) with a check interval range.
9. Vector
10. If you add an element to a container, use push_back () or back_inserter ().
11. Use Push_BACK () to Vector, not the regalog to Realloc ().
12. Capture public abnormalities in main ().
Fourth, type and statement
1. Maintain a smaller role.
2. Do not use the same name in a scope and its peripheral scope.
3. Only a name is declared in a statement.
4. Let common and local names are shorter, so that uncommonly used and global names are relatively long.
5. Avoid watching a similar name.
6. Maintain a unified naming style.
7. Choose the name carefully, reflect its meaning and not reflect the implementation.
8. If the internal type used indicates a variable value, use TypedEf to define a meaningful name.
9. Use typedef to define synonyms, define new types with enumeration or classes. 10. I must describe a type (Inti-INT ") in each statement.
11. Avoid unnecessary assumptions about character values.
12. Avoid unnecessary assumptions about the integer size.
13. Avoid unnecessary assumptions about floating point types representation.
14. Priority uses ordinary int instead of short int or long int.
15. Prioritize Double instead of float or long double.
16. Priority uses ordinary char than Signed Char or unsigned char.
17. Avoid unnecessary assumptions about the size of the object.
18. Avoid unsigned arithmetic.
19. You should take questions to see from Signed to Unsigned, or from unsigned to Signed.
20. You should look at the conversion from floating point to integer.
twenty one. You should look at the transition to a small type, such as converting Int to Char.
Five, advice
1. Avoid non-flat pointer arithmetic.
2. Beware, don't write over the boundaries of the array.
3. Try to use 0 instead of NULL.
4. Try to use Vector and Valarray, not an array of internal (C style).
5. Try to use String instead of the CHAR array ended with 0.
6. Try to use less common reference parameters.
7. Avoid VOID *, in addition to in some low-level code.
8. Avoid using non-flat text quantities ("Mysterious Number") in your code. Instead, various symbol constants should be defined and used.
