Writing code is an art, and recognizing mistakes is one of the important ways to improve our code. The following situations may not be encountered by everyone, but those who want to improve the quality of their code should take precautions. The following situations are common mistakes beginners make.
1.1 The string does not judge whether it is empty or not
1.1.1 Insert directly into the database
This situation often occurs in the java code of the server. When the information entered by the user is obtained from the form entered by the user, it is usually considered that the information entered by the client is the information we want and inserted directly into the database. As a result, many "null" values appeared in the database. For example, usually before saving to the database, you first need to splice sql, for example:
String name = paramsMap.get("name");
String gender = paramsMap.get("gender");
String sql= “insert into user（name,gender） values(‘”+name+
’,’”+gender+”’)”;
Normally, when the user fills in the name and gender, there is no problem with this code. But the reality is not as good as we imagined. Here, the value of name here usually has three cases, null, "null" (usually this case is not handled by the client) and "name", only the last one The situation is correct, the other two situations are not what we want. That is to say, the seemingly simple code only considers one-third of the cases, and the other two-thirds of the cases are not considered. As a result, this is why when we surf the Internet, when we check certain bills, we often see null, a "Chinese character" that users find confusing.
Correct spelling:
String name = paramsMap.get("name");
String gender = paramsMap.get("gender");
if(name==null || name=”null”){
name=””;//If it is empty, set it to empty, the database will not store the value
}
String sql= “insert into user（name,gender） values(‘”+name+
’,’”+gender+”’)”;
Of course, the above judgment method can also be written as a public method and called directly.
1.1.2 Direct interception
Take the above code as an example: what if we want to extract the first word in the name as a surname and store it separately? Look at the following code:
String name = paramsMap.get("name");
String lastName = name.substr(0,1);
String gender = paramsMap.get("gender");
String sql= “insert into user（name,last_name,gender） values(‘”+name+
’, ’”+ lastName +”’,’”+gender+”’)”;
There seems to be no problem. Under normal circumstances, this code has no problems at all. However, in an actual production environment, this code may keep reporting null pointer exceptions in the background. How about when the name is empty? Maybe you will say that control on the client side is a required item, so what if this is not a user's concern in business, and is not a required item? This is just an example. There are many similar codes in the program, and the parameters are always considered to be complete, and the parameters are in the format we imagine.
Correct spelling:
String name = paramsMap.get("name");
String lastName = "";//The default is empty
if(StringUtils.isNotBlank(name)){
LastName=name.substr(0,1)
}
String gender = paramsMap.get("gender");
String sql= “insert into user（name,last_name,gender） values(‘”+name+
’, ’”+ lastName +”’,’”+gender+”’)”;
The StringUtils class used is org.apache.commons.lang. StringUtils
1.2 Values based on location
In some regular form values, such as lists, we often use this method to get all the data items entered by the user, and then take the values in the order of html input, and then do further processing. However, the maintainability of this code is poor. For example: the original order is name, gender and age, now you need to insert a column in front of age, name is contact information, which disrupts the original order. Then all the code that takes the value must modify the order of taking the value. This is when the attributes of the list are relatively small. If there are more than 20 columns in a list, and the position to be inserted is the second column, then your tragedy coming soon.
Code example:
Var name = arr[1];
Var gender = scar [2];
Correct spelling:
Don't rely on property values, get values based on key values.
1.3 ID repetition
This is a common error in html. But when using extJs at the time, this error was difficult to troubleshoot.
Recommended method:
When naming the id, add a prefix, such as the user management interface, all IDs start with USER. Or enterprise users, add the company's domain name.
1.4 Code stacking
This is not a mistake. Usually, a method with more than 100 lines has poor readability. But as an enterprise, stability is the most expected result. Therefore, we only build on the code written by seniors. Modify, add functions, copy code and comment out old code. As a result, a method becomes more and more bloated, expanding from hundreds of lines to thousands of lines, or even tens of thousands of lines. Something went wrong, shirk responsibility, and say the code was written like this before.
Correct way:
If it is a new function, create a separate method to write the function, and only need one call or one judgment in the original method, instead of writing code directly in the original method.
If the original method is already bloated, split the code that can be isolated and then make changes.
1.5 Too Much Reliance on Clients
Such as time and date formats.
Perhaps, this is the tragedy of assigning tasks by module, if one writes client-side and server-side code, he can get that module to run just fine. But development only accounts for 20%, and we spend 80% of our time modifying a module. After the development is completed, the other group of people will spend 80% of their time fixing the bugs left by that person. Some of the more deeply hidden bugs are client-side trust. for example:
Example 1: The date is usually selected on the client side, and the format is fixed and correct. On the server side, you only need to get it and save it.
Example 2: Some dates are displayed to the user. The default is the current time, which cannot be changed. On the server side, it is only necessary to obtain and save.
The above are just two of the most common examples. What happens after the system is released? Some dates that are not valid date formats are also saved to the database. The default current time will appear after the current time. The submitted data is also inaccurate. This is because users do not necessarily play cards according to your ideas. He does not use your date control, or submits the data before the JS you use is loaded. Or the user's local time is wrong, and the current date you display by default is wrong. Or the user submits the data using some form submission tool.
Therefore, in the program, the server segment check ratio is indispensable, not only to check the data format, but also to check the logic. For example, the default time cannot be later than the current date.