Transferred from: http://www.cnblogs.com/finallyliuyu/archive/2010/09/25/1834301.html
On the naming rules of C + + variables
Do not know how other companies, anyway, I now the company on the name of the variable is not a certain specification, the only requirement is easy to understand, but, I think, this multiple programmers, probably everyone has their own habit of a set of naming rules, but, if not universal, probably look at other people's program will be very headache, so For others to see my program is not too headache, I decided to find a popular naming method to refer to, so, the search of the Hungarian name law ...
The origin and introduction of the Hungarian Nomenclature category: C Plus plus Hungarian nomenclature is a naming convention for programming. The basic principle is: variable name = attribute + Type + object description, where each object name requires a clear meaning, you can take the full name of the object or part of the name. Naming is based on the principle that easy memory is easy to understand. It is very important to ensure the consistency of the name.
For example, if the name of the form is a form, then the Hungarian nomenclature can be abbreviated as FRM, then the full name of the variable should be frmswitchboard when the form variable is named switchboard. This makes it easy to see from the variable name that switchboard is a form, and similarly, if the variable type is a label, it should be named Lblswitchboard. It can be seen that the Hungarian nomenclature is very easy to remember, and makes the variable name very clear and understandable, thus enhancing the readability of the code, convenient for each programmer to communicate with each other code.
This naming technique was proposed by a competent Microsoft programmer Charles Simonyi Charles Simonyi, who was born in Hungary. People who work with him in Microsoft company are taught to use this Convention. It's all normal for them. But for those outside the Simonyi-led project group, it was strange to think that it was a rigid expression, even with such a strange appearance because it was written in Hungarian. This naming method has been called the Hungarian nomenclature.
It is said that this nomenclature was invented by a Hungarian programmer named Charles Simonyi, who later spent several years at Microsoft, and the nomenclature spread through Microsoft's various products and documentation. Today, most programmers use this nomenclature, no matter what software they use to develop them. The starting point of this nomenclature is to combine the order of magnitude: attribute + Type + object description, so that programmers make variables with a visual understanding of the types and other properties of variables.
Here are the HN variable naming conventions, some of which are my personal bias:
Properties section:
Global variable G_
Constant C_
C + + class member variable m_
Static variable S_
Type section:
Pointer P
FUNCTION fn
Invalid V
Handle h
Long integral type L
Boolean b
Floating point type (sometimes referred to as a file) F
Dual-word DW
String sz
Short-integer n
Double precision floating point D
Count C (usually CNT)
Character ch (usually in C)
Integral type I (usually N)
BYTE by
Word w
Real Type R
unsigned u
Description section:
Max Max
Min min
Initialize Init
Temp variable T (or temp)
Source Object Src
Destination Object Dest
Here are a few examples to write about:
Hwnd:h is a type description, represents a handle, WND is a Variable object description, represents a window, so the HWND represents a window handle, PFNEATAPPLE:PFN is a type description, a pointer to a function, Eatapple is a variable object description, so it represents a pointer to EATAPPL The function pointer variable of the E function.
G_cch:g_ is a property description that represents a global variable, and C and CH are count types and character types, together representing the variable type, where the object description is omitted, so it represents a global variable that counts the characters.
Above is the general rule of the HN nomenclature.
Naming conventions for MFC, handles, controls, and structs Windows Type Sample variables MFC Class Sample variables
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 HPaltte; CPal ette* Ppalette; HRGN HRGN; crgn* prgn; HMENU HMENU; cmenu* Pmenu; hwnd hctl; cstate* pState; hwnd hctl; cbutton* Pbutton; HWND hctl; cedit* PEdit; hwnd hctl; clistbox* Plistbox; hwnd hctl; ccombobox* Pcombobox; hwnd hctl; cscrollbar* Pscrollbar ; HSZ hszstr; CString pStr; Point pt; CPoint pt; Size size; CSize size; rect rect; CRect rect;
Generic prefix naming specification prefix type
Instance class C or struct cdocument,cprintinfo m_ member variable m_pdoc,m_ncustomers variable naming specification prefix type description Instance ch char 8-bit character Chgrade ch TCHAR if _UNICODE is defined, then A 16-bit character Chname b bool Boolean value benable n int integer (its size depends on the operating system) nlength n UINT unsigned value (its size depends on the operating system) nheight W WORD 16-bit unsigned value wpos l LONG 3 2-bit signed integer loffset DW DWORD 32-bit unsigned integer dwrange p * Pointer pDoc LP far* far pointer lpszName lpsz LPSTR 32-bit string pointer lpszName lpsz LPCSTR 32-bit constant word The string pointer lpszName lpsz LPCTSTR If _UNICODE is defined, then the 32-bit constant strings pointer lpszName h handle Windows object handle HWND LPFN callback pointer to callback function far pointer prefix Symbol type instance scope idr_ multiple resource share identities for different types Idr_maiinframe 1~0x6fff Idd_ Dialog Resource Idd_spell_check 1~0x6fff hidd_ Dialog resource's help context Hidd_spell_c HECK 0x20001~0x26ff idb_ bitmap resource Idb_company_logo 1~0x6fff idc_ cursor resource idc_pencil 1~0x6fff idi_ icon Resource Idi_notepad 1~0x6fff ID_ to Commands from a menu item or toolbar id_tools_spelling 0x8000~0xdfff hid_ Command Help context hid_tools_spelling 0x18000~0x1dfff idp_ message box prompt idp_invalid_ PARTNO 8~0xdeef hidp_ message box Help context Hidp_invalid_partno 0x30008~0x3deff Ids_ string resource ids_copyright 1~0x7eef idc_ dialog box Controls IDC_RECA LC 8~0xdeef Microsoft MFC macro naming rulesFan name type _afxdll unique dynamic link Library,dll version _alpha only compiles Dec ALPHA processor _DEBUG includes diagnostic Debug version _mbcs compiled multibyte character set _unicode in one application The program opens Unicode AFXAPI functions provided by MFC CALLBACK The function library identifier by pointer callback identifier value and meaning U ANSI (N) or Unicode (U) d Debug or release: D = Debug; Ignore identifier for release.
Static library version naming specification library describes NAFXCWD.LIB Debug version: MFC static Connection Library NAFXCW. LIB release Version: MFC static Connection Library UAFXCWD. LIB Debug Version: MFC static connection Library UAFXCW with Unicode support. LIB release Version: MFC static connection library with Unicode support
Dynamic Connection Library Naming specification name type _afxdll unique Dynamic connection library (DLL) version WINAPI Windows provides a function Windows.h in the new naming specification type definition Description WINAPI Use the FAR Pascal location in the API declaration, if you are writing A DLL with an export API population point, you can use that type CALLBACK in your own API using the location of Far Pascal in the application callback routines, such as Windows and dialog boxes LPCSTR same as LPSTR, just LPCSTR for read-only string pointers, Its definition is similar to the (const char far*) UINT Portable unsigned integer type, whose size is determined by the host environment (for Windows NT and Windows 9x is 32-bit); it is a synonym for the unsigned int LRESULT the type of the return value of the window program LPARAM declares the type used by LPARAM, LPARAM is the fourth parameter of the window program WPARAM declares the type used by WPARAM, WPARAM is the third parameter of the window program lpvoid the generic pointer type, as in (void *), can be used instead of lpstr you can refer to this article by this link: http://wayllenzhang.bokee.com/tb.b?diaryId=12023505 char char BYTE Char szbuffer[] Char Szbuff_dest[] Init Ext csting M_szpatid
3rd Chapter naming rules
A more famous naming convention when pushing Microsoft's "Hungarian" law, the main idea of the naming convention is "to add prefixes to variables and function names to improve people's understanding of the program". For example, all character variables are prefixed with ch, and prefix p is appended if the pointer variable. If a variable starts with ppch, it indicates that it is a pointer to a character pointer.
The biggest drawback of the "Hungarian" law is that it is cumbersome, such as
int I, j, K;
float x, y, Z;
If the "Hungarian" naming convention is adopted, it should be written
int II, IJ, IK; prefix i denotes int type
Float FX, FY, FZ; Prefix f denotes float type
Such cumbersome procedures will make the vast majority of programmers unbearable.
According to the study, there is no naming rule that can be approved by all programmers, programming textbooks generally do not specify a naming convention. Naming rules are not "success or failure" for software products, and we should not devote too much effort to inventing the best naming rules in the world, but should develop a naming convention that satisfies most project members and implement them in the project.
3.1 Common rules
The common rules discussed in this section are adopted by most programmers, and we should expand specific rules, such as section 3.2, in accordance with these common rules.
L "rule 3-1-1" identifiers should be intuitive and can be spelt, it is expected to understand the text, do not have to "decode."
Identifiers are best used in English words or their combinations for easy memory and reading. Do not use Hanyu Pinyin to name. The English words in the program are generally not too complicated and the words should be accurate. For example, do not write CurrentValue nowvalue.
L The length of the "rule 3-1-2" identifier should conform to the "Min-length && max-information" principle.
A few decades ago, the old ANSI C stipulated that the name should not exceed 6 characters, the current c++/c no longer have this limitation. In general, long names can better express meaning, so the function name, variable name, class name up to more than 10 characters are not surprising. So the longer the name, the better? Not! For example, variable name maxval is more useful than maxvalueuntiloverflow. The names of single-character are also useful, common such as i,j,k,m,n,x,y,z, which can often be used as local variables within a function.
The "Rule 3-1-3" naming convention is consistent with the style of the operating system or development tool used.
For example, the identifier for a Windows application is typically in a "case"-mixed manner, such as Addchild. The identifiers of Unix applications are usually "lowercase underlined", such as Add_child. Don't mix the two types of styles together.
Do not appear in the "Rule 3-1-4" program with similar identifiers that are only case sensitive.
For example:
int x, x; Variable x is easily confused with X
void foo (int x); function Foo is easily confused with Foo
void FOO (float x);
In the "Rules 3-1-5" program, do not appear the exact same identifier local variables and global variables, although the scope of the two are different without a syntax error, but it is misleading.
The name of the "rule 3-1-6" variable should use "noun" or "adjective + noun".
For example:
float value;
float OldValue;
float NewValue;
The name of the "rule 3-1-7" global function should use "verb" or "verb + noun" (moving-in phrase). The member function of a class should use only "verbs", and the omitted noun is the object itself.
For example:
Drawbox (); Global functions
Box->draw (); member functions of the class
L "Rule 3-1-8" uses the correct antonyms group to name variables with mutually exclusive meanings or functions of the opposite action.
For example:
int minValue;
int maxValue;
int SetValue (...);
int GetValue (...);
2 "recommendation 3-1-1" Try to avoid the number of numbers in the name, such as value1,value2, unless logically required number. This is to prevent programmers from slacking off, and not to use their brains to produce meaningless names (because the number of numbers is the most convenient).
3.2 Simple Windows Application Naming conventions
The author makes a reasonable simplification of the "Hungarian" naming rules, and the following naming rules are simple and easy to use, which is more suitable for the development of Windows application software.
The "rule 3-2-1" class name and function name are combined with words that begin with uppercase letters.
For example:
Class Node; Class name
Class Leafnode; Class name
void Draw (void); Name of function
void SetValue (int value); Name of function
L "rule 3-2-2" variables and parameters are combined with words that begin with lowercase letters.
For example:
BOOL Flag;
int DrawMode;
L "rule 3-2-3" constants are all capitalized letters, with underscores for dividing words.
For example:
const int MAX = 100;
const int max_length = 100;
L "rule 3-2-4" static variable prefixed with S_ (representing static).
For example:
void Init (...)
{
static int s_initvalue; static variables
...
}
L "Rule 3-2-5" if a global variable is required, prefix the global variable with g_ (representing global).
For example:
int g_howmanypeople; Global variables
int G_howmuchmoney; Global variables
The data members of the "rule 3-2-6" class are prefixed with m_ (for member), which prevents the data member from having the same name as the parameter of the member function.
For example:
void Object::setvalue (int width, int height)
{
M_width = width;
M_height = height;
}
L "rule 3-2-7" to prevent conflicts in some identifiers and other repositories in a software library, you can add prefixes that reflect the nature of the software for a variety of identifiers. For example, all library functions for the three-dimensional graphics standard OpenGL begin with GL, and all constants (or macro definitions) begin with GL.
C + + variable naming conventions