When you change pits and fill pits, facing a new environment, being able to quickly and proficiently grasp the business requirements is the key.

But what can keep you from getting started quickly? Was the original code not written well enough? Or are the comments not good enough?


Last night, leisurely feeling refined, Chou Chou next door xiao Wang’s code, after seeing is really too angry, gas does not hit a place.

So, pull a list of mistakes made by Xiao Wang, help him improve, by the way look at these bad habits, do you also have?

1. Trust others too much and you will dig a hole for yourself.

The interface input parameters are not strictly verified, especially the parameters to be inserted into the database library. Once the data is transmitted to the bottom (database level), the database will report data insertion exception.

The caller waits for the interface to respond, and then gets a database error and is left stunned. For the interface itself, it will occupy database connections and consume resources. If there is a large amount of concurrency, the impact can be imagined.

Tip: During business code development, don’t trust callers to pass parameters as required, and program defensively.

2. I caught all of them, just a shiver away.

2.1. Catch an exception and do nothing!

2.2. The way to print the exception stack, however, is meaningless.

I think a lot of people will write this, but in production, it doesn’t make much sense, so it’s best to log the exception.

Suggestion: In the process of business code research and development, it is necessary to encapsulate and deal well with the exceptions occurred in the interface since the catch is carried out. Otherwise, the exceptions are swallowed up without any processing. Once there is a problem on the line, we do not know where the problem is.

3. Children’s problems will be careless and lose Jingzhou.

3.1. What is the user experience when the code is written like this?

For example, if a user is bound to a bank card, check whether the bank card is bound or not.

Loop through the list of bank cards bound to the user, and then compare whether the incoming card number (cardNo) has been bound. When the incoming card number is consistent with the bound card number, change hasCard to true, and continue the next comparison judgment without breaking out of the loop.

So, if this kind of code occurs in the scenario of large data volume, it is bound to reduce performance, excessive waste of resources, and users will definitely scold.

Suggested modification method (depending on your opinion) :

3.2. When data are processed one by one, why do they still slip through the net?

For example, when checking accounts among three parties, you can check whether the local status of the data sent by the three parties matches properly and deregister the unmatched data.

Once the conditions match and a record is deleted, the size of the list changes and the value of I changes, which will cause some records to be missed during traversal.

For example, if you drop the first element and continue to access the second element based on the index, the third element is actually accessed because the subsequent elements are moved one bit forward due to the deletion.

You are advised to use Iterator or reverse order traversal to delete the set.

3.3. Improper use of && & will eventually make mistakes.

For example, in a Web project, determine whether the input mailbox is empty.

When the email input is null, the following condition causes a null pointer exception when the & is used.

You are advised to change the value to:

Similarly, | and | | has a similar situation, therefore, when using, also to pay attention to the problem of such scenarios.

3.4. Equals comparison could be messy.

When resmap. get(global.retcode) is null, a null pointer exception occurs.

Since the equals method of Object is prone to null-pointer exceptions, business development should call equals using constants or objects with certain values.

You are advised to change the value to:

3.5. Math can break the bank.

Output: 0.010000000000005116. You can use java.math.bigdecimal wherever floating point operations are required.

You are advised to change the value to:

Note that the argument to construct BigDecimal is String. Make no mistake, this is a common problem for beginners.

3.6. Bizarre comments that make you want to curse.

3.6.1. Comments of a class in a project.

The author of the code is the administrator, dare to ask, who is the administrator TM? And the source file has been modified, but what is the description of the modification? Really puzzling!

3.6.2. Comments for a method in the project.

Method parameters are not explained; Method return value not interpreted; The author also belongs to the administrator; Modify description what does it describe?

4. Let the code do the talking.

4.1. Avoid selling water by the river.

4.1.1. Business interface verification code snippet.



Red circle live part, feel a little river selling water, superfluous action. Then, the false judgment can be removed, and it is suggested to modify as follows:

Similarly, in code development, the true criterion can also be removed.

4.1.2. User login code snippet.

The last else is a bit superfluous, can be omitted, can be changed to:

4.1.3. Whether the user binds the bank card fragment.

The judgment before return seems a little redundant, so you can change it to:

4.2. Reduce bugs and circle complexity.

You’ll find that the more nesting layers you have, the more complex your code is, and the higher its cyclomatic complexity is likely to be. However, controlling the number of nesting layers is an effective way to reduce the probability of bugs.

For example, the following code snippet is a handful in the project.



Based on the scenario, the following adjustments can be made:

4.3. Unified operation, code untouched, specification first.

In order to write code that can be read clearly, the premise is that the team should be unified, not for personal taste, and unique development of secrets.

Dare to ask, what needs to be unified?

  • Unified development environment (JDK version, INTEGRATED development tool IDE, storage directory…) ;
  • Unified development framework, more focus on business development;
  • Unified development template, development tools to carry out unified Scheme;
  • Unified development protocol, naming, annotation, code structure and other constraints;
  • Unified DB protocol, with a good standard.
  • Unified… .

5. The code farmers of the iron camp.

The code review process can make people laugh and cry! In order to let the colleagues who took over your code not scold you silently, it is suggested to treat coding this matter well and write each line of code carefully.

Writing code is a fun thing, and reviewing code is even more interesting. Through reviewing code, we can learn from each other, make the code more robust, and find bugs in advance, so don’t miss every time.

Finally, this time to share here, I hope you can like, if you think the article is a little help to you, please search wechat “a little ape talk” first time to read.