Good coding specifications

　1. Keep the method short and concise

Although many people follow this rule, it is still important. In general, the best way to write is to fully display the first screen . Just imagine, if you need to scroll the page to see the whole method, it is a very distracting thing. A method is best to stay between 5–20 lines , of course, you also have to depend on the circumstances, not generalize. For getter and setter methods, usually one line of code is required, so they look more like access accessors for class members.

　2. Never use the same variable for a different purpose

A variable should be used only for one purpose, and we can use constants (in C + + with the const identifier, final identity in Java), help the compiler to optimize code compilation, or identify to the program that "this variable cannot be changed", so that the code we write is better readable.

3. Make possible the names of variables and methods to describe the functions to be implemented.

An easy-to-understand program code, should be anyone just read the code, you can understand the program is used to do. Therefore, I suggest that you try to use fewer abbreviations, unless it is a well-known shorthand for the programming community.

4, as far as possible to define variables in the closest place to them

When you build a house, you don't want to put a hammer in someone's yard, instead, you put the tools of the building as close as possible and define the variables.

When you put a variable's declaration too far away from where it was used (or even more than one screen), it does bring you a lot of trouble. You will often scroll through the pages to look for this variable, which makes it difficult for you to maintain consistency between the code in your brain.

5, do not appear puzzling figures

At any time, when you want to compare constants, define them as constant types. The most frustrating thing about debugging code between teams is that the following code appears: Il < 4384

Replace it with the following code. Good: Inputlength < max_input_length

6. Treat your good language like a friend

Learning a new programming language is an interesting thing, where you can learn new things in a cool way. There is also a person who is very professional in a language to learn another language, many times it will be weak. For example, if you ask a Java Daniel to learn Ruby, he should use Ruby to solve the problem, rather than continue to follow Java's problem-solving ideas.

　

7, do not reverse the conventional line

Each programming language has its own binding habits, in general, you may learn more about Java programming habits, we look at some of these habits:

(1) The method name starts with a lowercase letter, followed by a word that begins with a capital letter, such as Verylongvariablename.

(2) The class name is generally a combination of words beginning with capital letters.

(3) The names of the constants are all uppercase words, separated by underscores, such as my_constant.

(4) The left curly brace should be on the same line as if.

Only when there is a compelling time to break this rule, do not like this practice and do not violate the already agreed coding practices. If you're part of a team and want to change some coding rules, that's fine, but when you share your code with teammates who don't have your habits, tricky questions come up.

8, be careful to optimize the code prematurely

Premature optimization is the root of all problems, at least that's what TV says ... Your first priority is to write easy-to-understand code without requiring you to write it quickly. Unless your program is running slowly, it's too early to talk about optimizations. If you want to optimize your program, then you have to find the problem of the program, which is why we need to profilers this tool.

To optimize your code without finding the source of the problem, the price you have to pay is to break the structure of the program, or at least lose the readability of the program. If you find that the program is running slowly, do not refactor the code blindly, first find the root cause of slow running.

Don't be silly to solve problems that don't exist at all.

10, do not indulge in excessive design skills

When I first came into contact with the concept of design patterns, I felt I had found the holy Grail. These ingenious design ideas can make your work smoother and make your design easy to understand, because you can simply say "I'm using the Observer pattern", and it's a lot of different explanations. However, since some of the problems seem too natural and simple, you can apply the idea of design patterns to any place, why not design this class as a singleton (singleton) model? Why not create some factory classes?

So with 80 lines of code to complete the script, the result you use 10 classes, 15 interfaces and a bunch of generics and comments, which 97% code does not do the actual thing. Design patterns, while useful, can help you simplify your design, but that's not to say you can use them everywhere. You can use design mode, but you can't abuse it.

9. Always refactor the tested code

There is no absolutely perfect thing in the world. Although you think your code has been written very well, you should often go to see it for some time, perhaps you will scold yourself: "How can be so silly!" ”

One way to improve the quality of your code is to refactor the code that passes the test often. The so-called pass test, I mean the program to be able to work properly, you can use automated testing or manual testing to ensure this.

First you want to make sure that the program works properly, the first time we don't need to write a perfect program, can use the line, then we can slowly refactor, let it gradually become perfect. This kind of development has the flavor of TDD, and the key is that you need to be familiar with every aspect of refactoring. If you are skilled in using some advanced Ides, like IntelliJ idea, your refactoring work will be much simpler.

11. Learn new knowledge anytime, anywhere

Programming is a work of learning new things, and when you learn a new class library or programming language, you can't wait to get rid of the old code and rewrite it. However, there are many reasons why you should not do so.

A similar problem arises when you apply a new class library or framework to an existing project. For example, you're writing JavaScript for a Web project, but when you find jquery in the middle, you can't wait to apply jquery and throw away the original JavaScript code, even if you didn't write any projects with jquery.

The best way to do this is to use jquery to learn to write simple examples of the techniques you need to use in your project. Say you want to use Ajax? Just write some simple examples of Ajax outside of the project and wait until you have mastered the old code to remove it from the project.

After the refactoring, you may encounter a lot of such problems, and even break the normal procedures, this is why we have to use automated testing. Once you're done refactoring, you can avoid these headaches by running the unit test again.

Good coding specifications