Writing high-quality code-starting with naming

Author: Johnny.liang Published: 2015-05-28 17:48 read: 3,444 recommendations: 30

Author engaged in development for many years, there is such a feeling, to see some open source projects, such as spring, Apache Common and other source code is a pleasing thing, the reason, no outside two points: 1) Code quality is very high, 2) naming special norms (this may be related to the English proficiency of foreigners).

To write high-quality code, not an easy thing, the need for a number of training, is a quantitative change to the process of qualitative change, but to write a good name, only need to have a better English grammar and a sense of self-awareness can be easily achieved. This blog will be combined with my development experience, summed up a number of naming rules, these naming rules are purely personal usage habits, does not represent an ideal rule, listed here for everyone to exchange discussions.

　　1. Do not use English letters without any meaning to name them

for (int i=0; i<10; i++) {    //...}

This is a common piece of code in many books that teach basic Java grammar, and as a teaching material, it is understandable, but as a real code writer, programmers must develop good habits, do not use this without any meaning of the naming method, you can use "index."

　　2. Do not use pinyin, or even pinyin first letter combination

Cishu =5;  Number of cycles Zzje = 1000.00;  Transfer amount

The author in the code check, countless times encountered such a name, make people laugh and cry.

　　3. To use English, and to use accurate English, whether it is spelling or grammar

• Noun singular, must use singular English, such as account, Customer.
• For the naming of collections of objects, such as arrays, lists, you must use complex numbers, and it is best to use accurate plural forms, such as list<account> accounts, set<strategy> strategies, in the basic knowledge of English grammar.
• For Boolean-valued properties, many developers are accustomed to using isxxx, such as isclose (whether closed), but there are two suggestions: 1) It is best not to take "is", because JavaBean's specification, when generating Get/set method for a property, uses the "get/set/ Is ", the above example, the generation of Get/set method will become" Getisclose/isisclose/getisclose ", very awkward; 2) since the Boolean value usually reflects" whether ", so the exact usage should be" adjective ", the above example, Should eventually be changed to closed, then Get/set method is "getclosed/iscolsed/setclosed", very accord with English reading habit.

　　4. The naming of method names requires the use of "verb-structure phrases" or "verbs + predicative structure phrases"

I have seen strange ways to name, some use nouns, some even "noun + verb", and, if the object is a collection of objects, it is best to use complex numbers.

Createorder (Order order)//good    ordercreate (Order order)//badremoveorders (list<order> orders)//good Removeorder (list<order> Order)//bad

　　5. For common "additions and deletions" method, the name is best to be cautious

• Add: The most common use of Create and add, but preferably based on the semantics of the English distinction, which helps to understand that create represents the creation, add represents the increase. For example, to create a student, it is better to use createstudent than with Addstudent, why? Consider if there is a class called clazz (class, avoid the Java keyword), now to add a Student to a clazz,clazz easily define a addstudent (Student Student) method, then it is more easily confused.
• Modification: Common have alter, UPDATE, modify, personal feel modify most accurate.
• Query: For getting a single object, you can use get or load, but the personal suggestion with get, explain see the description of the 7th, for non-conditional enumeration, with list, for conditional query, with search (preferably not with find,find in English to emphasize the results, is "found" meaning, You provide a "query" method that does not guarantee that the entered condition always "finds" the result.
• Delete: Common have delete and remove, but delete suggestion with delete, because remove has "remove" meaning, reference clazz example can understand, remove a student from class, will use Removestudent.

　　6. Rather lengthy method names, do not use the puzzling shorthand

I have encountered a method to determine whether the "payment account is the same as the beneficiary account", the result I see a name like this:

Checkisorderingacccollaccsame (...)

It's hard to understand, I'll change it right away:

Isorderingaccountsameascollectionaccount (...)

It's a bit long, but it's very easy to read, and it always happens to be less.

　　7. If you are designing a business system, it is best not to use technical terminology to name

The author once worked in the company has developed such a naming convention, the interface must start with "I", data transfer objects must be "DTO" as a suffix, the data Access object must be "DAO" as a suffix, the domain object must be "do" as a suffix. The reason why I don't recommend this approach is that I want designers to lead developers from the outset to consider issues from the "business" and not from "technology." Therefore, the interface does not need to be "I" start, as long as its implementation class with "Impl" End can be (note: I think the interface is not related to the details, and technology-independent, but the implementation of the class is related to the technical terminology is not delicious); The data transfer object, in fact, is to save the information of an object, **info ", such as CustomerInfo, the domain object itself is the core of the business, so still with its real name appear, such as account, Customer, as for" DAO ", this word originates from the design pattern of the Java EE, the author uses" * * * Repository "naming, meaning" * * * warehouse ", such as Accountrepository, the name of the word" Repository ", is derived from Eric Evans's" Domain-driven Design "a book of the warehouse concept, Eric Evans's concept of repository is defined as a conceptual collection of domain objects, which the individual considers to be very pertinent, which allows the programmer to completely get rid of the technical thinking and to think in terms of the business. Here, one might argue that good frameworks like spring and hibernate are not all using "I" as an interface, and "DAO" to name data Access objects. That's right! But don't overlook the semantic context, the Spring and hibernate frameworks are purely technical frameworks, and the scenario I'm talking about here is designing business systems.

　　8. Member variables do not repeat the name of the class

For example, many people like to use Accountid,accountnumber in the member variables of the account object, but it is not necessary to think that member variables do not have the presence of an isolated drum, you refer to AccountId, Must be Account.accountid, with Account.id is clear enough.

"Do not be good small and not for, do not use evil small and for it", "details determine success or failure", there are too many famous sayings tell us, to pay attention to details. A good programmer, must have a solid foundation, and for the naming rules so easy to grasp the basis, we do not present?

Writing high-quality code-starting with naming