Four harmful Java coding habits

The coding style in the program makes our programming work easier, especially for program maintainers, who often read code written by others. The coding specification fundamentally solves the problem of the program maintainer, it is easier to read and understand the code, and it can quickly and effortlessly draw on others ' coding. For those of you who will maintain your code in the future, the more you optimize your coding, the more they will like your code and the quicker you will understand it.

Similarly, a high level of coding style (such as a fixed closed structure) is designed to improve design and make coding easier to understand. In fact, some people end up thinking that improving the design and improving the readability of the code is one thing.

In this article you will see that some of the popular coding styles are replaced by a more receptive style for readers. Some argue that these styles have been widely used and should not be simply discarded in order to meet the expectations of the readers. However, the reader's expectations are only one of the reasons why it is impossible to override all factors. List four common problems:

1. There is no distinction between the naming of three variables (local variables), parameters (method arguments), fields (fields):

For those who look at the code, the first thing to figure out is how the data is defined? When you look at a class, you have to figure out where each entry is a local variable? Field? or a parameter? It is necessary to use a simple naming convention to define these variables to increase legibility.

Many authorities have normalized the field variable to differentiate it from other variables, but this is far from enough. The logical naming convention logic for a field can also be applied to parameters. Take a look at Example 1: There is no class definition that distinguishes these three variables, as follows:

Example 1:

public boolean equals (Object arg) {
　 if (! (arg instanceof Range)) return false;
　 Range other = (Range) arg;
　 return start.equals(other.start) && end.equals(other.end);
}

In this method, ARG uses the abbreviation of argument directly, although we can see that this is a parameter, but this kind of naming method loses the meaning of the object that the parameter represents. You know this is a parameter, but you don't know what the argument is. If the method has a bit more parameters, it's named after Arg1,arg2, which is a headache when reading the code. The other two field variables, start and end, suddenly out of thin air, think about it to know that this should be a field. Of course, this method is very short, caused the difficulty is not large, if this method is relatively long, suddenly see start and end two variables, usually first look at the front is not a local variable, and then to determine the class is a field variable.

This question seems trivial, but why should the code reader spend extra time on these trivial issues? If there is a scheme that allows code readers to see at a glance the variable is that variable, why not use it? As Steve McConnell in the Code encyclopedia: "It's no problem trying to figure out the mystery killer, but you don't have to think about the code, it's for reading."

Next look at example 2, after using the naming convention to rewrite the following code for example 1, the naming conventions used are:

Name prefix a when parameter definition

Name prefix f when field definition

The local variable is defined without any prefix

Example 2: Differentiating variable types

public boolean equals (Object aOther) {
　 if (! (aOther instanceof Range)) return false;
　 Range other = (Range) aOther;
　 return fStart.equals(other.fStart) && fEnd.equals(other.fEnd);
｝

You may object to the style in Example 2, against the outdated Hungarian symbol, but I think the objection is wrong, because the Hungarian symbol can specify the type of information.

The naming convention above distinguishes the type. And this is done by distinguishing between fields, variables, and local variables, which are two completely different concepts.

This naming convention is not as trivial as it may seem: when these conventions are used in code, it can greatly reduce the difficulty of understanding, because you don't need

To distinguish these variables first, save a lot of time.