Neo wrote a few days ago about the Naming and Design Thing in Programming, and here’s another article about naming programs from a different perspective.
1.- Variables should be as literal as possible. Do not use names in textbooks.
- Good variables: daysDateRange, flightNumber, carColor.
- Bad variables: days, dRange, temp, data, aux…
In our daily work, a large number of developers prefer to use short variable names rather than meaningful ones. This is mainly because of the examples in our college textbooks, people are preconceived, so the abstract, demonstrative naming of variables in textbooks has influenced generations of programmers and influenced them for years. And while those short, textbook variable names might make you type less, they’re really, really bad. Because software maintenance cost is far greater than the cost of development of software, if you don’t take a good bit of variable names, so when carries on the code review, when to bug fixing, when for code refactoring, when carries on the code maintenance, one of your variable name might make you confused about, don’t know their wits, can also make you walk into a trap, Cause more time cost. Therefore, a readable code is bound to have good variable names, which can lead to better quality software indirectly.
2.- Keep the variable names short and not too long
Only simple and short variable names are easy to read. Because your variable names must be used in program statements, to keep your program statements short, your variable names should also be short, or an expression will look complicated.
Of course, sometimes a meaningful variable name and a short variable name may conflict. This is a great exercise in language, if there are the most refined words to convey the most abundant meaning. If this is not possible, a meaningful variable name is better than a short one. Either way, we want to be short and rich in meaning, but if not both, meaning takes precedence.
- 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, such as: Use usr for user, gp for group, conf for configuration, CWD for current working directory, PTR for code point to reference, and so on. Abbreviations should always be legible rather than shortening a word for the sake of abbreviations, although it’s safer to comment out the shortened variable names. See Appendix I of this article for some conventional abbreviations.
Call waiting welfare
1. Recently sorted out 20G resources, including product/operation/test/programmer/market, etc., and Internet practitioners [necessary skills for work, professional books on the industry, precious books on interview questions, etc.]. Access:
-
Scan the code of wechat to follow the public account “Atypical Internet”, forward the article to the moments of friends, and send the screenshots to the background of the public account to obtain dry goods resources links;
2. Internet Communication Group:
-
Pay attention to the public account “atypical Internet”, in the background of the public account reply “into the group”, network sharing, communication;
4.- Use appropriate Hungarian naming conventions
Here’s a great Article in English on what is an appropriate Hungarian name and how to use it. Basically, Hungarian nomenclature is about adding a prefix to a variable that identifies the type of the variable or the function of a method. The basic principle is: variable name = attribute + type + object description.
For example, in describing types: pointer P, function fn, long integer L, Boolean B, floating point (and sometimes file) f, double-word dw, string sz, short integer n, double-precision floating point D, unsigned U… And so on. See Appendix II for more naming conventions.
Note that Hungarian naming also has its drawbacks. For example, if you want to change an integer to a floating-point type, you have to change the name of the variable as well as the type of the variable. This is quite troublesome. And, in some cases, the naming of prefixes can be overwhelming. In addition, in C++, this naming method is not easy to implement once you have a class. So it was crucial that the idea behind the Hungarian nomenclature was properly used.
5.- Don’t use anti-logical names
- Good name: IsEnabled.
- Bad name: IsNotEnabled.
When reading, we prefer positive logic to reverse logic. This rule goes beyond naming. In conditional statements, we should try not to use the opposite logic. Such as: the if (! (isAdmin | | isUser), such a statement is not consistent with the habit of reading the code, as it would be better – if (! isAdmin && ! IsUser).
6.- Be consistent
Keep all code consistent. Use the same naming conventions. There is no best naming convention in the world. But one thing is certain: in a code base, consistent naming rules should be used, even if the rules are not so good, but consistent throughout the team is good.
7.- Echoes the domain terminology of the application
Different ideas can have very specific and different meanings in different fields. For example, the word “order” does not always mean “order”, sometimes it means “order”, sometimes it means “order”, sometimes it means “rule”. So, certain words have different meanings in certain areas, so it takes our command to echo those areas.
Golden Rule – Take some time to think and weigh your variable names
When you design a variable name a function name, don’t rush to use it, stop and think, is the variable name appropriate, is there a better one? Maybe you’re using a bad variable name. Sometimes, we need to weigh the pros and cons, and maybe discuss it with colleagues.
In short, variable names are the first step in programming. The first step is good, and the next step is good. Imagine how much easier it would be for you or your colleagues to program with good variable names.
Appendix: Abbreviated specification of part
Complete the words | 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 |
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 nomenclature
A Array Array B BOOL (int) Boolean (integer) by Unsigned Char (Byte) C Char (Byte) CB Count of bytes Cr Color Reference Value Cx Count of x (Short) SET of x (Short) dw DWORD (unsigned long) f Flags fn Function Fn Function G_ global H Handle of the global I Integer L Long Long Integer LP Long Pointer Long pointer M_ Data member of a class N Short Int Short Integer P Pointer S String String SZ Zero terminated String terminated with 0 TM Text metric Text rule 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) coordinates v void emptyCopy the code
For global variables of the item, start with g_, for class member variables with m_, and for local variables that are large, consider l_ to indicate that they are local variables.
Prefix type examples g_ global variables g_Servers C class or structure CDocument, CPrintInfo m_ member variables m_pDoc, m_nCustomersCopy the code
VC common prefix list:
Prefix Type Description Example CH char 8-bit chGrade CH TCHAR 16-bit UNICODE chName B BOOL Boolean variable bEnabled n int Integer nLength n UINT Unsigned integer NLength w WORD 16-bit unsigned integer wPos l LONG 32-bit signed integer lOffset dw DWORD 32-bit unsigned integer dwRange P * Pointer to the memory module, 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 constant pointer LpszName H Handle Windows object handle hWnd LPFN (*fn)() Callback function pointer lpfnAbortCopy the code
Windows Object Name Abbreviations:
Windows object example variable MFC object 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; (Full text)Copy the code
Author: increasingly, blog: https://coolshell.cn/articles/18190.html