Share my thoughts and understanding on code naming

In the end, a software will be implemented in code, and the architectural design or design idea or model behind the code is important, but I think the more important thing is a good name. Chaotic or wrong naming not only makes it hard for us to understand the code, but worse, it will mislead our thinking and lead to a completely wrong understanding of the Code. On the contrary, a good name can make our code very easy to understand and express the essence of things and logic to readers correctly, thus greatly enhancing the maintainability of the Code.

In addition, we may not feel that it is good naming and naming habits. Because we always have very strict requirements on the name of each concept, we will think about whether the concept expressed by this name is correct, and whether the name correctly expresses the essence of a thing or correctly reflects the logic of a behavior. Therefore, this kind of good naming habits can, in turn, help us correct some previous error designs and code implementations. For example, you may have a problem with inaccurate naming, then you will find that there is another place that needs this name, and it is more reasonable. So you will find that this name is not suitable for the previous place, so you will think about the previous place may need other names, or you will find that there is a problem with the design above. This is an example of whether your design is correct.

I think the main reasons for confusion or incorrect naming are:

1. Not understanding the nature of things;
2. I understand the nature of things, but I don't know the importance of naming or the root cause of naming;
3. I understand the nature of things and the importance of naming, but I cannot name things well;

Therefore, to develop good naming habits, I have summarized some of my ideas:

1. Strict self-discipline. When writing code, you must have a strong awareness and strict self-discipline consciousness that each name should be named;
2. Efforts should be made to analyze and think about the nature of the thing or logic you have named. This is critical. If you do not think deeply, it will lead to a naming error for this thing, because you haven't figured out what things you named are;
3. On the basis of self-discipline awareness and certain analytical capabilities, pay attention to naming methods and techniques. You must know when to use a verb, when to use a noun, where to put a adjective, where to put a verb, and where to put a noun; that is, the primary and the secondary class will be used;
4. Make sure that the naming style of each similar part of your program is consistent. Do not use uppercase letters for a while, or lowercase letters for a while; Use the Pascal naming method for a while, and use the camel naming method or the Hungarian naming method for a while;
5. Do not duplicate names; because names are usually nested. For example, if a class is in a namespace and a method is in a class, if a concept is expressed in a namespace, you do not have to express it again;
6. For an attribute or class name, it should always be at the end of the term. The term determines what this attribute represents. The previous part is used to modify this term. For example, if you have a service, then there is an order-related service, which can be named orderservice. In this way, it tells us that this is a service, then an order service, and then cancelordercommand, when we see this, we know that this is a command, that is, a command, and then what command? Is a command to cancel the order, cancelorder indicates to cancel the order;
7. For methods, it should always start with a verb and end with a noun; for example, order. additem (orderitem); this indicates that the Order class has a method to add order items. Add is a verb, indicating adding, and item is a noun indicating order items;

Next, let's take a look at some of the code that is not well named to know what details should be noted during the naming process:

There are many problems in the above Code. Let's analyze them one by one:

1. Parameters of the method, the first letter, the capital P for a moment, and the lowercase P for a moment, inconsistent;
2. The second parameter is followed by extra spaces;
3. _ Paramstable why does this parameter have to be underlined, while other parameters do not have to be underlined or inconsistent;
4. Publishrequest belongs to the camel naming method, while isigncounter and sstageisok belong to another naming method. Many different naming methods are used in C ++;
5. In a foreach loop, the parameter name is instparam, but the following set is called arrparams4signactions. The more symmetrical one is called arrinstparam;
6. The last two lines of the method have redundant spaces, leading to messy code format layout;

From the above code, we can know that many problems can be found only through these details. When writing code, we only need to be careful and pay more attention to whether the typographical style is consistent and whether the names are uniform. Then the code will be much more beautiful. Next let's look at other code:

1. In the code above, the names of the two parameters are also inconsistent. In projectid, I is in lower case, but in publishid, I is in upper case and should all be in upper case;
2. The keys in viewdata are updated in uppercase at a time, and are named differently at a time;
3. The above two red boxes show only one line of code, but one with parentheses and one with no parentheses, which are inconsistent. In addition, the second if contains extra blank lines, chaotic format;

1. In the above Code, the function uses ilist for a while, which is an interface. The dictionary, non-interface, and inconsistency are used for a while. APIs should be used or none of them are used;
2. The names of listoriginal and receiverlist are inconsistent, either starting with all lists or ending with all lists;
3. In a foreach loop, the variable type is tdmsoriginalrequirement, but the variable name is originalitem, and the Set Name is also called listoriginal. The three variables should be unified. For example, foreach (Assembly in assemblies)
4. + Space is not used in the place of "...". spaces must be placed on both sides of the plus sign. This is a messy and not rigorous place;
5. The createuser variable is not ideal. "CREATE" is a verb. "createuser" means to create a user. "CREATE" means to create a user, so it should be called "createduser" or "creator;
6. Why is the meaning of originalitemformat and originalitem equivalent? It is unreasonable. If it is equivalent, it must be named originalitemformat at the beginning. Besides, format is a thing, and verbs are placed at the end. What is the meaning?

1. Some of the private fields in the above class contain namespaces, some do not, or both. Generally, namespaces are declared on the top and do not need to appear in the future;
2. Ilog logger; there are two problems with this sentence: 1) Why does the logger have no underscores and is not uniform; 2) Why is the class named ilog and the variable named logger? Either the class name is ilogger, either the variable name is _ log;

The two private methods above, one starting with uppercase and the other starting with lowercase, are inconsistent and chaotic; they should be consistent;

Through some examples above, we know that when we accidentally write a space, an empty row, or a letter with different uppercase and lowercase letters, the names will be inconsistent; if you do not develop this habit of paying attention to the consistency of code naming, the written code is probably as above. I think it is very bad. The examples above are only simple naming. In fact, there are many other things to note. The most important thing is that we must strictly abide:

1. The name of any attribute must be consistent with the meaning actually represented by it;
2. What you do in any method must be the same as the name in this respect;

Otherwise, the code will be highly readable.

 

Share my thoughts and understanding on code naming