11 Steps to improve code quality and overall productivity

This article is about 11 things I've learned over the years as a professional programmer to really improve my code quality and overall productivity.

1. Never copy Code

Avoid duplicate code at any cost. If a commonly used code fragment appears in several different parts of the program, refactor it and put it into one of its own functions. Duplicate code can cause your colleagues to be confused when reading your code. Duplicate code that changes in one place and forgets to change in another place can create bugs everywhere, and it can make your code bulky. Modern programming languages provide a good way to solve these problems, for example, the following problem is difficult to solve before, but now the use of Lambdas is well implemented:

<summary>
///Some functions contain partial duplicate code
///</summary>
void Originala ()
{
dothingsa ();

Unique Code

DOTHINGSB ();
}

<summary>
///Another function with partially duplicated code
///</summary>
void Originalb ()
{
Dothingsa        ();

No duplicate Code

DOTHINGSB ();
}

Now we refactor the functions that contain some of the same code and rewrite them in delegate mode:

<summary>
///encapsulate shared functionality
///</summary>
///<param name= "Action"        >user defined action</param>
void Uniquewrapper (Action action)
{
dothingsa ();

Action ();

DOTHINGSB ();
}

<summary>
///New implmentation of A
///</summary>
void Newa ()
{
Uniquew Rapper (() =>
{
//unique Code
});
}

<summary>
///New Implementation of B
///</summary>
void Newb ()
{
Unique Wrapper (() =>
{
//unique Code
});
}

2. Notice when you start to get distracted.

When you find yourself browsing Facebook or Twitter rather than solving the problem, this is usually a sign that you need a short break. Leave your desk, have a cup of coffee, or talk to co-workers for 5 minutes. While this may seem counterintuitive, it will improve your productivity in the long run.

3. Do not rush to the task and abandon the principle

When you are under pressure to solve a problem or modify a bug, it is easy to lose self-control, find yourself in a hurry, or even completely forget the important testing process that you have been insisting on. This usually leads to more problems that can make you look unprofessional in the eyes of your boss or co-workers.

4. Test your completed Code

You know what your code can do, and try it, it does work, but you actually need to validate it fully. Analyze all possible boundary conditions and test all possible conditions for it to work as scheduled. If there are parameters, pass some values outside of the expected range. Passes a null value. If possible, let colleagues look at your code and ask if they can break it. Unit testing is the usual way to achieve this.

5. Code review

Before submitting your code, sit down with a co-worker and explain to him what changes you have made. Often, you can find errors in your code without needing a colleague to say a word. This is much more effective than reviewing your own code.

6. Make less code

If you find that you've written a lot of code to solve a simple problem, you're probably doing it wrong. The following Boolean usage is a good example:

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

Then you should write this:

Enabled = nummines > 0;

The less code the better. This causes fewer bugs, less refactoring possibilities, and less chance of error. Be modest. Readability is equally important, and you can't do that to make your code less readable.

7. Work for elegant Code

Elegant code is very easy to read, with very little code handy, so that the machine can do very little operation to solve the problem. It's hard to do code elegance in a variety of environments, but after a while, you'll have a rudimentary sense of what elegant code looks like. Elegant code is not acquired by refactoring. When you see the elegant code it will be very happy. You'll be proud of it. For example, here's a way I think it's elegant to compute the polygon area:

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. Writing self-explanatory Code

Annotations are an important part of programming, but the ability to be self-explanatory is a good idea because it allows you to understand the code when you look at it. Function name Variable name to choose carefully, good variable/method name in the language semantic environment, people who do not know how to program can understand. For example:

void Damageplayer (player player, int damageamount)
{
if (!player.m_isinvincible &&!player.m_isdea D)
{
player.        Inflictdamage (damageamount);
}
}

Code that can be explained by itself cannot replace annotations. Annotations are used to explain "why", whereas the self-describing code describes "what is".

9. Do not use pure digital

Embedding numbers directly into your code is a bad habit because you can't say what they represent. It's even worse when there's repetition--the same number appears in multiple parts of the code. If you only modify one, and forget the other. This results in a bug. Be sure to use a named Changshilai to represent the number you want to express, even if it appears only once in the code.

10. Do not do manual labor

As a series of actions, man always likes to make mistakes. If you're working on a deployment, and you're not doing it one step at a moment, you're doing something wrong. As much as possible to automate the completion of work to reduce human error. This is especially important when it comes to heavy workloads.

11. Avoid premature optimization

When you're going to optimize a functional code that's already working, you're probably going to break it. Optimization can only occur when a performance analysis report indicates a need for optimization, usually in the final stages of a project development. Optimization activities prior to profiling are a waste of time and can cause bugs to occur.