10 Programming Tips you need to know

Summary: Why do you strike a good code? Good code can be defined as easy to read, easy to understand, easy to debug, easy to change, and most importantly less defective. Obviously, it takes a lot of time to strike out a good code, but it makes sense in the long run, because you can spend less time and effort to maintain and reuse your code. This is a summary of an old programmer from a 30-bit software experience.

Why knock out good code?

Good code can be defined as easy to read, easy to understand, easy to debug, easy to change, and most importantly less defective. Obviously, it takes a lot of time to strike out a good code, but it makes sense in the long run, because you can spend less time and effort to maintain and reuse your code.

In fact, we can equate good code with reusable code, which is one of the important principles mentioned below. The code may just be a specific feature of a short-term goal in programming, but if no one (including yourself) is willing to reuse your code, the code can be somewhat inadequate and flawed in some way. Either too complex, too specific, or very likely to collapse under different circumstances, or other programmers may not believe your code.

Regardless of your level of experience, if you consistently apply the following tips to your code (including your experiments or prototypes), a good code is handy.

1. Follow the principle of single responsibility

Functions are the single most important form of abstraction in the programmer's library. The more opportunities you can reuse, the less code you write, and the more reliable the code will be. Small functions that follow the principle of single responsibility are more likely to be reused.

2. Minimize shared status

The implicit sharing state between functions should be minimized, whether it is a file-scoped variable or an object's member field, which facilitates the explicit use of the desired value as an argument. The code becomes easy to understand and reuse when the explicit function implements the desired result.

You can draw a conclusion that you should prioritize static stateless variables instead of the object's member variables.

3. Localized side effects

Ideal side effects, such as printing to the console, logging, changing the global state, file system operations, and so on, should be placed in separate modules rather than scattered throughout the code. Functional side effects often violate a single principle of responsibility.

4. Choose the Immutable object first

If the state of an object is set once in its constructor and does not change again, debugging becomes much easier because it remains valid once it is constructed correctly. This is one of the easiest ways to reduce the complexity of software projects.

5, multi-use interface less use class

Functions that accept interfaces (or template parameters or concepts in C + +) are more reusable than functions that operate on classes.

6, the principle of good application of the module

Break down software artifacts into smaller modules, such as libraries and applications, for modular reuse. Some key principles of the module are:

1. minimizing dependencies

2. Each project should have a single, clear function

3. Don't repeat

You should try to keep your project small and clear.

7. Avoid inheritance

In object-oriented programming, inheritance, especially virtual functions, is often a dead hole in terms of reusability. I rarely succeed in using libraries that can overwrite classes.

8. Testing as with design and development

I'm not a hardcore supporter of test-driven development, but when you start writing test code, writing tests naturally follows a number of guidelines. It also helps to expose errors early. Avoid writing useless tests, and good coding means more advanced testing (for example, integration or functional testing in unit tests) is more effective at displaying defects.

9. Preference rather than handwriting standard library

I can't tell you how long it will take to see an std:: vector or std: A better version of string, but it's almost always a waste of time and effort. Except for the obvious fact that you are introducing bugs to a new place. (see Tip 10) Other programmers are less likely to reuse your code than those that are widely understood, supported, and tested.

10. Avoid writing new code

Most important of all, each programmer should follow: "The best code is the code of thatisn ' t written" (the most desirable codes are not to be made up of the duplicate codes). The more code you have, the more defects you have, and the more difficult it is to find and fix bugs.

Before you write a line of code, ask yourself, is there a tool, function, or library that has done what you need? Do you really need to implement this feature yourself instead of invoking another feature that already exists?
Summarize
Programming is like an art form or a sport, and you can constantly improve the quality of your code by constantly practicing and learning from others, which will help you become a more efficient programmer.