If a good project is named properly or not, 30% of the project quality can be seen at the first glance. Therefore, the following is an excerpt:
7 + 1 tips in programming naming
Naming in programming is a basic skill, but there are many things to be aware. Bad naming is often confusing. This article provides seven suggestions and a golden rule. In short, the variable name is the first step in programming. The first step is well followed.
AD:
The author provides 7 + 1 tips for programming naming:
1.-variables should be as simple as possible. Do not use the naming method in the teaching material.
◆ Good variables: daysDateRange, flightNumber, and carColor.
◆ Bad variables: days, dRange, temp, data, aux...
In our daily work, a large number of developers prefer to use short variable names in programming naming, rather than 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 name, when performing code reviews, when performing bug fixing, during code refactoring and code maintenance, some of your variable names may make you confused, unaware of the measures, and may make you fall into a trap, this causes 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 in programming naming 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 variables: howLonDoesItTakeToOpenTheDoor, howBigIsTheMaterial...
◆ Good variables: 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, see Appendix 1 in this document.
4.-Use appropriate Hungarian programming 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 programming naming 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, see appendix 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 to name Programming
◆ Good name: IsEnabled.
◆ Bad name: 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: Abbreviations and specifications
Full abbreviations
A
Average avg
B
Back bk
Background bg
Break brk
Buffer buf
C
Color cr, clr
Control ctrl
D
Data dat
Delete del
Document doc
E
Edit edt
Error err
Escape esc
F
Flag flg
Form frm
G
Grid grd
I
Increment inc
Information info
Initial init
Insert ins
Image img
L
Lable lab
Length len
List lst
Library lib
M
Manager mgr, mngr
Message msg
O
Oracle Ora
P
Panorama pano
Password pwd
Picture pic
Point pt
Position pos
Print prn
Program prg
S
Server srv
Source src
Statistic stat
String str
Sybase Syb
T
Temp tmp
Text txt
U
User usr
W
Window win, wnd
Appendix II. Hungarian naming law
A Array
B BOOL (int) Boolean (integer)
By Unsigned Char (Byte) Unsigned characters (bytes)
C Char character (byte)
Cb Count of bytes
Cr Color reference value Color (reference) value
Cx Count of x (Short) x set (Short integer)
Dw DWORD (unsigned long) Dual-character (unsigned long integer)
F Flags mark (generally a multi-digit value)
Fn Function
G _ global
H Handle
I Integer
L Long integer
Lp Long pointer
M _ Data member of a class
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 is 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_Servers
C Class or struct CDocument, CPrintInfo
M _ member variables m_pDoc, m_nCustomers
List of common VC prefixes:
Prefix type Description Example
Ch char 8-character chGrade
Ch TCHAR 16-bit UNICODE Character chName
B BOOL Boolean variable bEnabled
N int integer nLength
N UINT unsigned integer nLength
WWord 16-bit unsigned integer wPos
L LONG 32-bit signed integer lOffset
Dw DWORD 32-bit unsigned integer dwRange
P * Memory Module pointer, pointer variable pDoc
Lp FAR * long pointer lpDoc
Lpsz LPSTR 32-Bit String pointer lpszName
Lpsz LPCSTR 32-bit constant string pointer lpszName
Lpsz LPCTSTR 32-bit UNICODE type constant pointer lpszName
H handle Windows object handle hWnd
Lpfn (* fn) () callback function pointer lpfnAbort
Abbreviation of Windows Object Name: www.2cto.com
Windows Object example variable MFC class example object
HWND hWnd; CWnd * pWnd;
HDLG hDlg; CDialog * pDlg;
HDC hDC; CDC * pDC;
HGDIOBJ hGdiObj; CGdiObject * pGdiObj;
HPEN hPen; CPen * pPen;
HBRUSH hBrush; CBrush * pBrush;
HFONT hFont; CFont * pFont;
HBITMAP hBitmap; CBitmap * pBitmap;
HPALETTE hPalette; CPalette * pPalette;
HRGN hRgn; CRgn * pRgn;
HMENU hMenu; CMenu * pMenu;
HWND hCtl; CStatic * pStatic;
HWND hCtl; CButton * pBtn;
HWND hCtl; CEdit * pEdit;
HWND hCtl; CListBox * pListBox;
HWND hCtl; CComboBox * pComboBox;