7 + 1 tips in programming naming)

A few days ago, Neo wrote "Naming design in programming". Here there is another article andProgramNamedArticle, You can look at it from another perspective.

1.-variables should be as informative as possible

• Good variable: Daysdaterange, flightnumber, carcolor.
• Bad variable: Days, drange, temp, Data, aux...

In our daily work, a large number of developers prefer to use short variable names instead of meaningful variable names. This is mainly because examples of university textbooks are preemptible. Therefore, those examples in textbooks are abstract and named with demonstrated variables, which affects programmers from generation to generation, and affected them for many years. Although the short and textbook variable names may lead to less words, it is very bad. Because the maintenance cost of the software is much higher than the development cost of the software, if you do not take a better variable nameCodeDuring the review, when performing bug fixing and code refactoring and code maintenance, some of your variable names may make you confused and confused, it can also make you fall into the trap, resulting in greater time costs. Therefore, a readable code is bound to be inseparable from those good variable names, and this can also make your software indirectly have a better quality.

 

2.-The variable name should be as short as possible.

Only simple and short variable names are easy to read. Because your variable name must be used in program statements, your variable name should be shorter to make your program statements look short, otherwise, a written expression will become very complicated.

Of course, sometimes there may be some conflicts between a meaningful variable name and a short variable name. This is an exercise of our language ability-if there are the most refined words to express the most abundant meaning. If it is not possible, it is better to get a meaningful variable name than to get a brief variable name. In any case, we want to be short and have rich meanings, but if they cannot be both, they have a higher priority.

• Bad variable: Howlondoesittaketoopenthedoor, howbigisthematerial...
• Good variable: Timetoopenthedoor, materialsize.

3.-Abbreviations can be used, but some comments are required.

Sometimes, we need to use abbreviations to name variables. For example, USR is used to represent users, GP is used to represent groups, and conf is used to represent configuration, use CWD to represent current working directory, use PTR to code point to reference, and so on. Abbreviations are generally used for understanding, rather than shortening a word for abbreviations. Of course, if you add a comment to the variable name after the abbreviations, it is more secure. For some common abbreviations, refer toAppendix 1.

4.-Use the appropriate Hungarian naming rules

Here is a very good English article to tell you what is a proper name for Hungary. This article also tells you how to use it. Basically, the Hungarian naming method adds a prefix to a variable to identify the type of the variable, or is a function of a method. The basic principle is: variable name = property + Type + object description.

For example, in terms of description types: pointer P, function FN, long integer L, Boolean B, floating point type (sometimes also referred to as a file) F, double-character DW, string SZ, short integer N, double Precision Floating Point D, unsigned u ...... And so on. For more naming conventions, seeAppendix 2.

Note that the name of Hungary is also bad. For example, if you want to change an integer to a floating point type, you need to change the name of the variable in addition to the type of the variable. This is quite troublesome. In addition, in some cases, such prefix naming can make you feel overwhelmed. In addition, in C ++, this naming method is not easy to implement after the class is available. Therefore, the idea behind the proper use of Hungary naming is critical.

5.-Do not use anti-logic for naming.

• Good name: Isenabled.
• Bad naming:Isnotenabled.

During reading, we prefer positive logic rather than reverse logic. This rule is not just named. In condition statements, we should try not to use this opposite logic. For example, if (! (Isadmin | isuser), such a statement does not conform to the user's habit of reading the code, so it is better to write it -- if (! Isadmin &&! Isuser ).

6.-Maintain consistency

Maintain the consistency of all codes. Use the same naming rules. There is no best naming convention in the world. One thing is certain, that is, a consistent naming rule should be used in a code library. Even if this rule is not so good, it is good for the entire team to use the same one.

7.-additional domain terms for Applications

In different fields, different ideas have very special and different meanings. For example, the word "order" does not always mean "suborder". Sometimes it means "order", sometimes "command", and sometimes "rule ". Therefore, some words have different meanings in a certain field. Therefore, we need to attach the commands to these fields.

 

Golden law-Take some time to think about how to weigh your variable name

When you design a variable name and a function name, don't worry about using it. Stop and think about it. Is this variable name suitable? Is it better? Maybe you are using a bad variable name. Sometimes, we need to weigh the pros and cons and discuss them with our colleagues.

In short, the variable name is the first step in programming. The first step is well followed. Imagine how easy it is for you or your colleagues to program using some good variable names.

 

Appendix Hungary naming law

A array B bool (INT) Boolean (integer) by unsigned char (byte) unsigned character (byte) C char character (byte) CB count of bytes Cr color reference value color (reference) CX count of X (short) x set (short integer) dw dword (unsigned long) dual-character (unsigned long integer) f flags mark (usually a multi-digit value) FN function g _ global Global H handle I integer l long integer LP long pointer M _ data member of a class data member n short int short integer P pointer s string SZ zero terminated string ending with 0 TM text metric text rules u unsigned int unsigned integer ul unsigned long (ulong) unsigned long integer W word (unsigned short) unsigned short integer x, y X, Y coordinates (short) coordinate value/short integer v void empty

The global variables of the project start with G _, and the class member variables start with M _. If the local variables are large, you can use L _ to show that they are local variables.

 
Prefix type example g _ global variable g_serversc class or struct cdocument, cprintinfom _ member variable m_pdoc, m_ncustomers
 

List of common VC prefixes:

 
Example of prefix type description ch char 8-character chgradech tchar 16-bit Unicode type character chnameb bool Boolean variable benabledn int integer nlengthn uint unsigned integer nlengthw word 16-bit unsigned integer wposl long 32-bit symbol integer loffsetdw DWORD 32-bit unsigned integer dwrangep * Memory Module pointer, pointer variable pdoclp far * long pointer lpdoclpsz lpstr 32-Bit String pointer lpsznamelpsz lpcstr 32-bit constant string pointer lpsznamelpsz lpctstr 32-bit Unicode type constant pointer lpsznameh handle windows object handle hwndlpfn (* fN )() callback function pointer lpfnabort
 

 

 
From: http://coolshell.cn/articles/1038.html