Coding quality issues from programming naming

Many people think that it takes a lot of exciting innovation to improve the coding quality and a significant leap. this is probably true, but I personally feel that it is a great effort to improve the coding quality in the project, it is necessary to accumulate step by step, and the methodology is mostly not helpful. Start with the name. When we see a design drawing or a piece of code, most people will [hope ].

Many people think that it takes a lot of exciting innovation to improve the coding quality and a significant leap. this is probably true, but I personally feel that it is a great effort to improve the coding quality in the project, it is necessary to accumulate step by step, and the methodology is mostly not helpful.

Start with the name.

When we see a design drawing or a piece of code, most people will [hope ]. However, it is the fundamental mission of words and languages. Therefore, if a function is named "Add ()", but the internal operation is subtraction, this design or the code will be hard to understand.

So a very realistic question is placed in front of us: how should we name classes, methods, and so on?

In terms of naming, there are two major traps: one is not real name, and the other is word obfuscation.

There are two common cases of non-real name inconsistency. For example:

• To be partial. Assume that a method is named OutputLineNumber (). However, after analyzing the source file, this method outputs both the LineNumber and the content under the specified row number.
• It is big but not big. If a class is named XMLHandler, it means that the user cannot obtain valid information from the class name. This is mainly because the meaning of Handler is too broad.

The name mentioned above is "Add ()", but the actual subtraction operation is an extreme case of non-real name inconsistency, reaching the opposite point of name reality. Word-meaning obfuscation originates from the restrictions of the language and text itself. It is often manifested as a multi-word or multi-word.

A linguistic character can be regarded as an ideographic symbolic system. The typical feature of this symbolic system is its ambiguity. There are many expressions for the same meaning. For example, index and number are two different words, but often their meanings overlap. If a variable is named fileNumber, this variable can represent both the total number of files and the number of a specific file.

The above problems will become more troublesome because English is not our mother tongue.

One of the main triggers of such traps is the continuous evolution of the software itself. As mentioned in previous articles, cognition of concepts and logic is a progressive process.

In this process, the connotation of packages, classes, and methods will inevitably change. Changes will undoubtedly aggravate problems such as non-real names. For example, if a class is originally responsible for outputting test results, it may be appropriate to name OutputTestResult. With the enhancement of software functions, the results may not be output, but the results must be analyzed and analyzed. In this way, some of the original names are not suitable.

After analyzing the root cause of naming, let's take a look at the possible solutions.

In fact, the naming problem cannot be solved only in the naming process. First, there must be objects that are easy to name, and then there must be facts that are easy to name. For example, if there are animals with different external characteristics such as cats and dogs, then we will use different names such as cats and dogs to name them, rather than the opposite.

If the concepts are orthogonal and the boundary of the concepts is clear, it will be much easier to name them. Good design is the basis for improving naming. That is to say, we often feel that naming is difficult. the real reason may not be that the naming skills are insufficient, but that the design is not optimized.

Only after efforts are made to improve the design can we face pure naming issues. In essence, naming is not a programming issue, but an expression issue. Naming is ultimately the responsibility of the reader.

Some basic expressions are helpful for solving naming problems, such:

• Respect for facts

No doubt everyone is creative, but it is more harmful to give full play to creativity during naming. For example, in the XML world, sibling is generally used to represent sibling nodes. in this case, you do not need to use brother creatively? Self-made words like node.

• Complete Vocabulary

? For average people, they need to remember dozens of acronyms in advance, but later reading the program is unlikely. So if a program is filled with special characters such as _ Tx and CSCP, such a program is almost understandable.

A typical inverse example is P. J? Plauger C ++ Standard Template Library. Perhaps for the purpose of hiding implementation details, the implementation of this Standard Template Library almost does not need a complete word. If you want to experience the consequences of not having to use a complete vocabulary, you can read the code below .?

• To be specific

It is a specific direction. For example, you can use OutputLinenumber () instead of Output (). You can use OutputCppLinenumber () instead of OutputLinenumber ().

• ? Unified specifications are used for multi-person collaboration

This rule will eventually lead to the so-called Coding? Rule. How to define Coding? Rule, the book "code Daquan" provides detailed guidance, which is not described here.

One thing to add is that, just as you can't remember the syntax when talking, people who design or code often cannot remember the encoding rules. Therefore, too many rules should not be applied. If it must be detailed, it should be at least distinct. For example, if you choose whether to use the primary object structure or the dynamic object structure, most of the content of the program will be affected.

This article is available at http://www.nowamagic.net/librarys/veda/detail/1757.