C++ itself as an object-oriented language, first introduce the object-oriented development principles involved in general.
First, object-oriented development principles
1. Dependence Inversion Principle:
For interface programming, rely on abstraction rather than concrete, abstraction (stability) should not depend on implementation details (change), implementation details should depend on abstraction, because stable states become unstable if they depend on change.
2. Principles of openness and closure:
Open to expansion, close to modify, business needs are constantly changing, when the program needs to be extended, do not modify the original code, and flexible use of abstraction and inheritance, increase the scalability of the program, easy to maintain and upgrade, classes, modules, functions, etc., can be extended, but not modified.
3. Single responsibility principle:
A class does only one thing, a class should have only one cause for its change, and the direction of change implies the responsibility of the class.
4. Richter’s Substitution Principle:
A subclass must be able to replace a parent class, and any reference to a base class must be able to use its subclass transparently, one of the concrete implementations of the open-close principle.
5. Interface isolation Principle:
The interface should be minimized and complete, and public should be minimized to reduce external interaction, and only external methods should be exposed.
6, at least know the principle:
An entity should interact with as few other entities as possible.
7. Encapsulate the point of change
Do a good demarcation, keep one side change, one side is stable, the calling side is always stable, the called side can change inside.
8. Prioritize composition over inheritance
Inheritance is a white-box operation, while combination is a black-box operation. Inheritance destroys encapsulation to some extent, and the coupling degree between parent class and child class is relatively high.
9. Programming for interfaces
Instead of programming for implementation, emphasize interface standardization.
C++ development principles
The above understanding of object-oriented development principles can be refined to specific C++ development principles.
1. Keep it simple and direct:
Keep the code as simple as possible, introduce flexible points of variability into the code if the requirements require it, and only add locally complex things that make the whole simpler.
2, do not need the principle:
Always implement them when you really need them, not when you just foresee that you’ll need them in the future, and write code when you really need them, when it’s too late to refactor.
3. Principle of avoiding duplication:
Do not copy, do not duplicate, this is a very dangerous operation, when you modify one part of the code always remember to modify the other or more parts of the code that you have copied?
4. Information hiding Principle:
One piece of code calls another piece of code. Callers should not know the implementation of the called code, or they may modify the implementation to implement something that may cause bugs in other callers.
5. Principle of high cohesion and low coupling:
Similar to the single responsibility principle, specify the specific responsibilities of each module and rely as little as possible on other modules.
6, the least surprise principle:
Do you want to change a member variable’s value in a getter() function?
7, cleaner principle:
When you leave the campsite, you should leave the campsite cleaner than before you arrived. When you find any code that needs improvement or has a bad style, you should change it immediately. Do not care who the original author of this code is, nor whose module it is, code ownership is collective. Every team member should be able to make changes and extend any code at any time.
Focus on unit testing
Not to mention the importance of nip it in the back, especially when you’re building a large system, unit testing, code quality, can nip it in the back.
Generally pay attention to test-driven development, the development of a function should first think about how to test, first write the test code, and then develop the corresponding requirements. Unit testing is also helpful for developers to better interface design, mainly the principle of good unit testing.
1. Unit testing principles
To ensure the quality of the unit test code, the unit test code is also code, should not be treated differently from the product code, and the unit test code to write bugs will affect the test efficiency.
2. Unit test naming
Each test unit needs to be named according to the specific test content, which is convenient for locating and analyzing problems. If problems occur, problems can be located by the name of the test unit.
3. Make unit tests independent
Each test unit is independent and does not depend on other test units. Do not build the context of the test unit.
4. Try to ensure that each test unit uses one assertion
To ensure a relative independence within the test unit, the above assertion hinders the following assertion test is also bad design.
5. Make the unit test environment independent
Make sure that each test unit has its own environment, not dependent on other environments, that each test unit is a separate running instance, and that the environment is cleaned up after each unit test.
A larger view mode
6. You don’t have to do unit tests
There is no need to unit test third-party libraries and external systems, only test your own code.
7. Unit testing should not involve databases
Database state is global, tests are not guaranteed to be independent, and database access is slow, affecting the speed of unit testing. If necessary, you can simulate database testing in content, which is usually done at the system integration and system test levels.
Test code and production code
Don’t confuse test code with production code; you shouldn’t rely on test code in production code.
9. Tests must be performed quickly
Make sure that unit tests on large systems are only a few minutes in seconds and don’t access peripherals like databases, disks, networks, etc.
10. Find test surrogates
For example, if some data needs to be retrieved from the web, you can use dependency injection (DI) to create a class that simulates the generation of that data. Look at Google Mock.
Four, good naming
Good naming of functions and variables is essential, regardless of the language, because the name of the function tells us what the code in the function does, not by writing comments.
1. File naming
File names should be all lowercase, followed by _, and the suffix should be.cc and.h
2. Type naming
Each word of the type name is capitalized and does not contain underscores: MyExcitingClass, MyExcitingEnum.
3. Variable naming
Do not include the type of a variable in the name. If the type of a variable changes later, you will need to change the name of the variable. Take full advantage of the IDE, lowercase variables (including function parameters) and data member names
4. Constant naming
A variable declared as constEXPr or const, or whose value remains constant for the duration of the program,
5. Function naming
The general function uses mixed case, and the value and set function must match the variable name:
MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().
Copy the code6, enumeration naming
Consistent with constant
7, Tip:
Do not use meaningless names unless they are obvious, such as TMP in swap. The function name and variable name should be very long and clearly defined. Do not use abbreviations.
5. Editor
The team can use the same editor. Currently, I am using VS Code editor, and each project uses the same.clang_format file with the same standard Code format. All newlines should be in LF format instead of CRLF format.
The personal. Clang-format file is as follows, with some modifications in the Google style:
Summary of key points of coding specification
Use #define for each header file to avoid double references
A larger view mode
Or use #pragma once, where #define is more generic
Encourage the use of anonymous namespaces or static declarations in.cc files. When a named namespace is used, its name can be based on the project name or relative path. Disallow inline namespace using directives
2, a line should not exceed 120 characters, a function should not exceed 40 lines, and a file should not exceed 500 lines.
3. All reference parameters are const if left unchanged. Use const or constexpr whenever possible
4. Use smart Pointers for new memory. In c++11, replace STD ::unique_ptr with STD ::auto_ptr
5. Use mobile semantics wisely, reduce memory copying, refer to lvalue references, rvalue references, mobile semantics, perfect forwarding, what you know and don’t know is all here
Do not use RTTI, try to determine parameter types at compile time, and do not use code that recognizes TypeID at runtime
7, use C++ casting, such as static_cast<>(). Do not use conversions like int y = (int)x or int y = int(x)
8. Specify the specific meaning of using the prefix ++ or the suffix ++. If the return value is not considered, try to use the efficient prefix ++ (++ I).
9. Do not use uints. If you need to use large integers, consider int64
Don’t use macros unless you have to. Instead, use const or constexpr instead. Macros have cumbersome global scopes. If you must use macros, use #define immediately and #undef immediately
11. Google Docs says never use macros to control conditional compilation (I haven’t found out how to control conditional compilation without macros myself, so probably don’t do conditional compilation)
Use sizeof(varname) instead of sizeof(type) whenever possible. Sizeof (varname) is used because it is automatically updated when the variable type changes in the code. You might use sizeof(type) to handle code that doesn’t involve any variables, such as data formats from outside or inside, where variables are not appropriate
13. Use the auto keyword if the type name is too long
Don’t disable code with comments. Use Git well. Don’t write comments for code that is easy to understand
15, Remember the format after writing the Code, VS Code(Windows shortcut keys) Shift + Alt + F, each project should have a uniform. Clang_format file.
16, use C++ string and stream instead of C style char*, STD ::ostream and STD ::cout instead of printf(), sprintf(), etc
17, try to use STL library containers rather than C-style arrays, arrays of out-of-bounds access is not error, but may dirty stack information, resulting in strange and difficult to troubleshoot bugs
18. We can use more template metaprogramming, using constexpr and other compilers as much as possible. Compilers are our good partners, and I think template metaprogramming will become a mainstream technology in C++
19. Consider using exception handling rather than C-style errno, etc. Is your C ++ team still disabling exception handling?