Developing C + + programs in the next tense

Good software adapts to change. It provides new features, adapts to new platforms, meets new requirements, and processes new inputs.

The new function will be added to the library, and the new overload will occur. Notice the result of the ambiguous function call behavior; The new class will join the inheritance hierarchy, and now the derived class will be the base class of the future, ready for this; New applications will be compiled and functions will be invoked in the new running environment. They should be written to run correctly on the new platform; The maintainer of the program is usually not the person who originally wrote them, so it should be designed to be understood, maintained, and expanded easily by others.

One way to do this is to use the C + + language itself to express design constraints, not annotations or documents. For example, if a class is designed to not be inherited, do not simply add a comment to its header file, and use C + + methods to block inheritance.

If a class needs its instance to be all created in the heap, don't just say that to the user and force it with the method described earlier.

If copy construction and assignment are meaningless to a class, they are blocked by declaring them to be private.

It is important to judge the meaning of a function and whether it is redefined by a derived class. If it is meaningful, declare it to be virtual, even if no one immediately redefined it. If it is not, declare it to be non-virtual and do not change in the future for the convenience of someone; make sure that the change is meaningful for the entire class's running environment and for the abstractions represented by the class.

Handle assignment and copy constructors for each class, even if "nobody has done this before". Their failure to do so now does not mean that they will not do so in the future. If these functions are difficult to implement, declare them private. In this way, no one will mistakenly adjust the default version provided by the compiler and do something wrong (this happens frequently on default assignment and copy constructors).

Based on the law of least surprise: efforts to provide such classes, their operations and functions have natural syntax and intuitive semantics. Consistent with the behavior of the built-in data type: When you are undecided, do it in the form of an int.

Admit it: As long as it can be done, someone else does it (WQ: Murphy's Law). They throw the anomaly, they assign it to themselves, they use the object before the initial value is assigned, the object is assigned a value, it is not used, and the value is too large, the value is too small, or the null value is assigned. In general, anyone would do this if they could compile it. So, make your class easy to use correctly and hard to misuse. To acknowledge that a user can make a mistake, design your class to prevent, detect, or fix these errors.

Working on portable code. Writing portable code is no more difficult than a portable code, and it is only desirable to use a non portable structure when performance is extremely important. Even programs designed for specific hardware are often ported because these platforms will have an order of magnitude performance improvement within a few years. Portable code makes it easier for you to change platforms, expand your user base, and brag about supporting an open platform. It also makes it easier to make a mistake in the operating system. The impact is local when you design your code properly to change. Encapsulate as much as possible, and declare implementation details private. Use a nameless namespace and static objects or functions within a file whenever possible. Avoids the design of the virtual base class, because it requires each derived class to initialize it directly-even those indirectly derived classes. Avoid the need for RTTI design, it requires a if...then...else-type waterfall structure. Each time the class's inheritance level changes, each group of if...then...else statements needs to be updated, and if you forget one, you will not get any alarms from the compiler.

The consideration of future tenses simply adds a few additional constraints:

• Provides a complete class, even though some parts are not currently in use. If you have new needs, you don't have to go back and change them.

• Design your interface to facilitate common operations and prevent common errors. Make the class easy to use and not easily used incorrectly. For example, block copy construction and assignment operations if they do not make sense to this class. Prevents partial assignment.

• If there is no limit to how you can not use your code, then use it in a generic format. For example, if you are writing a tree traversal algorithm, consider using it universally to handle any circular graph.

Future tense considerations add to your code's reusability, maintainability, robustness, and ease of modification as the environment changes. It must be compared with the constraint conditions of the progressive tense. Too many of the programs are focused on the needs of the moment, but they sacrifice the long-term viability of their software. Is different, is deviant, in the next tense development program.