11 key points to be mastered by excellent programmers and 11 key points to be mastered by programmers

11 key points to be mastered by excellent programmers and 11 key points to be mastered by programmers

Next, I will be a professional programmer with many years of programming experience and share some of the essence-they have helped me improve my code quality and overall work efficiency, I hope it will also benefit you.

1. never repeat the code

Avoid repeated code at all costs. If you often use a code snippet in a few different places, you can reconstruct it into a function. Code duplication will not only lead to confusion in reading, but also cause bugs -- fixed the repeated fragments here, but omitted from other places. It will also lead to bloated code libraries and the expansion of executable file sizes. The current programming language can greatly improve this problem. For example, the following sample code is difficult to solve before the delegate and lambda expressions appear:

1234567891011121314

/// /// Some function with partially duplicated code/// void OriginalA(){DoThingsA();// unique codeDoThingsB();}/// /// Another function with partially duplicated code/// void OriginalB(){DoThingsA();// unique codeDoThingsB();}

But now, we can reconstruct the above Code to form a function, or rewrite it using a delegate:

1234567891011121314151617181920212223

/// /// Encapsulate shared functionality/// /// User defined actionvoid UniqueWrapper(Action action){DoThingsA();action();DoThingsB();}/// /// New implmentation of A/// void NewA(){UniqueWrapper(() =>{// unique code});}/// /// New implementation of B/// void NewB(){UniqueWrapper(() =>{// unique code});}

2. Be careful not to be distracted

When you find that you are using Facebook and Twitter-you cannot focus on solving the problem, it often means you have to take a break. Leave your desk for a cup of coffee and chat with your colleagues for five minutes. Don't think this is a waste of time. In the long run, this will make you more productive.

3. think twice about the solution

The solution and bug fixes that come up with high pressure can easily be overwhelmed, leaving the critical test cycle that is always remembered. But this will often lead to more problems and make you look less professional in the eyes of your boss and colleagues.

4. Code of test completion

You know what your code should do and may have been tested, but you need to prove this. Analyze all possible Edge Conditions and give a test to determine that your code can be executed normally under all possible conditions. If a parameter exists, some values out of the expected range are sent. You can also send null values. If you can, let your colleagues do the damage-unit testing is a formal road to prosperity.

5. Code Review

Before you submit the code to the source code control, it is best to explain your changes to your colleagues. Sometimes you only need to do this to make you aware of your code errors, even if your colleagues do not make a statement. This is much more efficient than simply reviewing your work.

6. Simplified code

If you use a lot of code to execute some simple operations, it is likely that you are on the wrong path. The following is a good example of Boolean processing:

12345678

if (numMines > 0){enabled=true;}else{enabled=false;}

But you can write it like this:

1	enabled = numMines > 0;

The simpler the code, the better-less debugging, fewer refactoring, and fewer problems. However, readability is equally important. No one wants to streamline the code and affect the readability of the Code.

7. Try to write elegant code

The so-called elegant Code not only has a strong readability, but also can solve the problem at hand with the minimum amount of code and machine operations. It is actually quite difficult to achieve code elegance in all circumstances, but after some time of programming, you will gradually realize what the "elegant code" should be like. Elegant Code cannot be improved through refactoring-be proud of it. The following code example for calculating the Convex Polygon Area is what I think is "elegant code ":

1234567891011

static public double GetConvexPolygonArea(Vector2[] vertices){double area = 0;for (int i = 0; i < vertices.Length; i++){Vector2 P0 = vertices[i];Vector2 P1 = vertices[(i + 1) % vertices.Length];area += P0.Wedge(P1);}return area / 2;}

8. Compile self-document code

Annotation is a very important part of programming, but self-document code is better because it can be understood only by reading the code. By cleverly selecting the function name and variable name, and then contacting the language semantics, you can make the code readable, even if the reader is not a programmer. For example:

1234567

void DamagePlayer(Player player, int damageAmount){if (!player.m_IsInvincible && !player.m_IsDead){player.InflictDamage( damageAmount );}}

However, self-documented Code cannot replace comments. Use annotations to explain "why" and use self-document code to describe "what ".

9. Do not use strange numbers

It is wrong to insert numbers into the code, because no one can understand what they represent. This obfuscated us-when the same number is used in different places in the code. Some may cause changes and some may generate bugs. Use a named constant to describe the value to be expressed, even if it is used only in one place.

10. Automation

It is easy to make mistakes when we perform a series of actions. If your deployment process involves more than one step, you may encounter an error. We should be as automated as possible to reduce human error opportunities. Automation is especially important if you need to execute many tasks.

11. Avoid Premature Optimization

Once you start to optimize the code that can be successfully run, there is a risk of function destruction. Optimization should only respond to performance analysis at the end of the project. Optimization ahead of the analysis phase will not only waste time, but also lead to bugs.

12. Top 10 programming taboos that programmers must pay attention

Programmers will inevitably encounter such errors during programming. In addition to learning from the errors, we can also learn from the experiences of our predecessors to avoid these errors. (This article is very worth reading. The title is hyperlink)