How to write good Java code? why?

Introduction: It is very important for programmers to write good code, so we must always remind ourselves: Did your code write well today?

What do we often overlook?

Often programmers are under pressure on the project to complete certain functions hastily, so:

1. Irregular naming (for example, there is a parameter a and a method b)

2. The amount of code of the method is very large, and the code of a method is as long as hundreds or even thousands of lines.

3. No comments or almost no comments

4. Does not form a certain code style, such as line breaks, indentation, brackets, etc.

5. No log printing (log printing helps us find and debug problems)

Let’s do some analysis on the problem.

1. Standard naming

Naming principle: once we see the name, we can basically understand what this parameter means and what this method does

For example: b() and insert() these two methods, we can easily know that the latter is an "insertion" method. When the former was written, we knew what it was for. What about half a year or more later? Then you can only look at the implemented code (if you tell me: "I have a lot of time, I like to look at it like this", then I will give you a thumbs up)

Second, the method is compact (code reconstruction)

Principle: Limit the size of the method to be visible on one page of the screen

Method: If one of our methods is more than a page, then we must consider refactoring it, transfer some functions to another method, and do a good job of naming and passing parameters.

Programmers usually analyze their own code after finishing the work, and then do refactoring work. If you pay attention to and are good at refactoring, the code you write will be cleaner and stronger.

Three, reasonable use of notes

Principle: Please use comments (5 words that are so unpretentious)

Misunderstanding: My code is written so hard, so perfect, do I still need to comment?

actual:

1. The code you write is often not so careful, you may just do the work

2. Although we work hard, the code is not as perfect as we thought, or just feel perfect by ourselves.

Future: If you make a comment, you , your colleagues, friends, and people who read your code may thank you!

Fourth, the unification of code style

Principle: Use a unified style (for example, the company's unified code style, if not, use Java standard writing)

Misunderstanding: Coding style is a personal preference, I can write whatever I want

Actually: Your colleague read the code you wrote and silently clenched his fist (you can think about it yourself)

Such as:

public static void main(String[] args) {

}

The following two are not recommended

public static void main(String[] args)
{
}

public static void main(String[] args)
  {
  }

Another example:

for(int i=0;i<10;i++){
   System.out.println(i);
   System.out.println(i);
   System.out.println(i);
   System.out.println(i);
   System.out.println(i);
}

It is not recommended to write:

for(int i=0;i<10;i++){
System.out.println(i);
System.out.println(i);
System.out.println(i);
System.out.println(i);
System.out.println(i);
}

Even like this:

for(int i=0;i<10;i++){
System.out.println(i);System.out.println(i);System.out.println(i);System.out.println(i);System.out.println(i);
}

Five, log printing

Principle: Print logs reasonably (Log4j is recommended, it is divided into several printing levels, very suitable)

Misunderstanding: Why do you print the log? My code is perfect, very robust, no problem with the test, just so confident

actual:

1. As mentioned before, your code may not be so perfect, so robust

2. During production, there are some problems that you did not expect, and you need to log to show through the log

3. Some unexpected conditions at runtime

Suggestion: We need to print logs in more critical locations, which can be used to analyze process trends and analyze errors

Others: It is also a good way to use a database to record logs. For example, the round-trip message of the interface is recorded in the table, which can effectively improve the efficiency of our daily maintenance. (Sometimes there are a lot of log prints, and the log is not easy to check; or there are more servers, you have to look through them one by one, and you may cry)

 

Finally: 80% of the life of a software product is in maintenance, and the person who maintains it is often other people, not the author. It is conceivable how important good code is.