Writing high-quality code -- starting with naming and writing high-quality code -- starting with naming

I have been engaged in development for many years and have such a feeling that viewing some open-source projects, such as spring, Apache common, and other source code is a pleasing thing. The reason is that there are no other two points: 1) the code quality is very high; 2) Special naming rules (this may be related to the English proficiency of foreigners ).
Writing high-quality code is not an easy task. It takes years to work out. It is a process from quantitative change to qualitative change, but you must write a good name, you only need to have a good English grammar foundation and a kind of self-consciousness. This blog post will summarize several naming rules based on my development experience. These naming rules are purely personal habits and do not represent an ideal rule, for discussion.
1. Do not use English letters without any meaning for naming:
For (INT I = 0; I <10; I ++ ){
...
}
This is a common piece of code in many books that teach the basic syntax of Java. As a teaching material, this writing is understandable. But as a real code writing, programmers must develop good habits, do not use this naming method without any meaning. here we can use "Index ".
2. Do not use Pinyin or even the combination of the first letter of the alphabet:
Cishu = 5; // number of cycles
Zzje = 1000.00 // transfer amount
I have encountered such a name countless times during code check, which makes people laugh and cry.
3. Use English and accurate English, whether spelling or grammar:

• The singular number of nouns. the singular English letters, such as account and customer, must be used.
• The names of arrays, lists, and other object sets must use the plural number, and it is best to use an accurate plural form according to the basic knowledge of the English syntax, for example, list <account> accounts and set <stragety> strageties.
• For the attribute of Boolean value, many developers are used to using isxxx, such as isclose (whether to close). However, there are two suggestions: 1) it is best not to include "is" because of the javayan specification, when the get/set method is generated for the property, "Get/set/is" will be used. In the above example, the get/set method will be generated to "getisclose/isisclose/getisclose ", (2) because the Boolean value usually reflects "whether", the correct usage should be "adjective". In the above example, it should be changed to closed, the get/set method is "getclosed/iscolsed/setclosed", which is very suitable for English reading.

4. to name a method, you must use the "verb-object structure phrase" or "Verb + Table-language structure phrase". I have seen some strange naming methods and some use nouns, some are even "Nouns + Verbs". If the object is an object set, it is better to use the plural:
Createorder (order) Good
Ordercreate (order) bad
Removeorders (list <order> orders) Good
Removeorder (list <order> order) bad
5. Exercise caution when naming common "add, delete, modify, and query" methods:

• Add: Create and add are the most common features, but it is better to distinguish them based on the English meaning, which helps to understand. Create indicates creation, and add indicates addition. For example, to create a student, it is better to use createstudent than addstudent. Why? Think about it. If there is a class named clazz (class, avoiding Java keywords), and now we want to add a student to a clazz, clazz can easily define a method of addstudent student, it is easy to confuse.
• Modify: Alter, update, and modify are common. I personally think modify is the most accurate.
• Query: You can use get or load to obtain a single object, but you are advised to use get. for explanations, see the description at. For list without any conditions, use list. For Conditional queries, use search (it is best not to use find. Find emphasizes the result in English, which means "find". You provide a "query" method, it is not guaranteed that the input conditions can always "find" the result ).
• Delete: delete and remove are common, but delete is recommended for deletion. Because remove means "Remove", you can see the clazz example to remove a student from the class, removestudent is used.

6. I would rather name the method in a long way than using the obscure shorthand. I once encountered a method to determine whether the payment account is the same as the payment account:
Checkisorderingacccollaccsame (...) is hard to understand. I will change it:
Isorderingaccountsameascollectionaccount (...), although a little long, but very easy to read, and this situation always appears less.
7. If you are designing a business system, it is best not to use technical terms for naming. The company I used to work on has formulated such naming rules. The interface must start with "I" and the data transmission object must be suffixed with "DTO, the data access object must be suffixed with "Dao" and the domain object must be suffixed with "do". The reason why I do not recommend this practice is that the designer wants to guide developers from the very beginning, consider the problem from the perspective of "business", rather than from the perspective of "technology. Therefore, an interface does not need to start with "I", as long as its implementation class ends with "impl" (note: the interface is irrelevant to the details and has nothing to do with the technology, but the implementation class is related to implementation, and there is no cool in technical terms), while the data transmission object is actually nothing more than saving the information of an object, so you can use "** Info ", for example, customerinfo, the domain object itself is the core of the business, so it still appears with its real name, such as account and customer. As for "Dao", this word comes from the J2EE design mode, in my previous project, I used the "*** repository" name, which means the "*** repository", such as accountrepository and the name of the word "repository, it is a repository concept derived from Eric Evans's book domain-driven design. Eric Evans defines the repository concept as a conceptual set of domain objects. I personally think this name is very appropriate, it allows programmers to get rid of the technology and stand Business perspective. Speaking of this, some may argue that not all excellent frameworks such as spring and hibernate start with "I" and use "Dao" to name data access objects? That's right! However, do not ignore the semantic context. Spring and hibernate frameworks are pure technical frameworks. The scenario I mentioned here is to design business systems.
8. do not repeat the class names. For example, many people prefer to use accountid and accountnumber names in the member variables of the account object. It is not necessary to think that the member variables will not be isolated, you reference accountid, which must be an account. accountid. Use account. the ID is clear enough.
"Do not take good and small, do not take evil and small for it", "Details determine success or failure", there are too many famous saying that we should pay attention to details. A good programmer must have a solid foundation, and the naming rules are easy to grasp. Why not do we have a solid foundation?