举例来说，表单的名称为form，那么在匈牙利命名法中可以简写为frm，则当表单变量名称为Switchboard时，变量全称应该为 frmSwitchboard。这样可以很容易从变量名看出Switchboard是一个表单，同样，如果此变量类型为标签，那么就应命名成 lblSwitchboard。可以看出，匈牙利命名法非常便于记忆，而且使变量名非常清晰易懂，这样，增强了代码的可读性，方便各程序员之间相互交流代码。

据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在，大部分程序员不管自己使用什么软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把量名变按：属性+类型+对象描述的顺序组合起来，以使程序员作变量时对变量的类型和其它属性有直观的了解，下面是HN变量命名规范，其中也有一些是我个人的偏向：

 

 

匈牙利命名法MFC、句柄、控件及结构的命名规范

Windows类型	样本变量	MFC类	样本变量
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；	CPalette*	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；

 

一般前缀命名规范

前缀	类型	实例
C	类或结构	CDocument，CPrintInfo
m_	成员变量	m_pDoc，m_nCustomers

 

变量命名规范

前缀	类型	描述	实例
ch	char	8位字符	chGrade
ch	TCHAR	如果_UNICODE定义，则为16位字符	chName
b	BOOL	布尔值	bEnable
n	int	整型（其大小依赖于操作系统）	nLength
n	UINT	无符号值（其大小依赖于操作系统）	nHeight
w	WORD	16位无符号值	wPos
l	LONG	32位有符号整型	lOffset
dw	DWORD	32位无符号整型	dwRange
p	*	指针	pDoc
lp	FAR*	远指针	lpszName
lpsz	LPSTR	32位字符串指针	lpszName
lpsz	LPCSTR	32位常量字符串指针	lpszName
lpsz	LPCTSTR	如果_UNICODE定义，则为32位常量字符串指针	lpszName
h	handle	Windows对象句柄	hWnd
lpfn	callback	指向CALLBACK函数的远指针	?

 

应用程序符号命名规范

前缀	符号类型	实例	范围
IDR_	不同类型的多个资源共享标识	IDR_MAIINFRAME	1～0x6FFF
IDD_	对话框资源	IDD_SPELL_CHECK	1～0x6FFF
HIDD_	对话框资源的Help上下文	HIDD_SPELL_CHECK	0x20001～0x26FF
IDB_	位图资源	IDB_COMPANY_LOGO	1～0x6FFF
IDC_	光标资源	IDC_PENCIL	1～0x6FFF
IDI_	图标资源	IDI_NOTEPAD	1～0x6FFF
ID_	来自菜单项或工具栏的命令	ID_TOOLS_SPELLING	0x8000～0xDFFF
HID_	命令Help上下文	HID_TOOLS_SPELLING	0x18000～0x1DFFF
IDP_	消息框提示	IDP_INVALID_PARTNO	8～0xDEEF
HIDP_	消息框Help上下文	HIDP_INVALID_PARTNO	0x30008～0x3DEFF
IDS_	串资源	IDS_COPYRIGHT	1～0x7EEF
IDC_	对话框内的控件	IDC_RECALC	8～0xDEEF

 

Microsoft MFC宏命名规范

名称	类型
_AFXDLL	唯一的动态连接库（Dynamic Link Library，DLL）版本
_ALPHA	仅编译DEC Alpha处理器
_DEBUG	包括诊断的调试版本
_MBCS	编译多字节字符集
_UNICODE	在一个应用程序中打开Unicode
AFXAPI	MFC提供的函数
CALLBACK	通过指针回调的函数

库标识符命名法

标识符	值和含义
u	ANSI（N）或Unicode（U）
d	调试或发行：D = 调试；忽略标识符为发行。

 

静态库版本命名规范

库	描述
NAFXCWD.LIB	调试版本：MFC静态连接库
NAFXCW.LIB	发行版本：MFC静态连接库
UAFXCWD.LIB	调试版本：具有Unicode支持的MFC静态连接库
UAFXCW.LIB	发行版本：具有Unicode支持的MFC静态连接库

 

动态连接库命名规范

名称	类型
_AFXDLL	唯一的动态连接库（DLL）版本
WINAPI	Windows所提供的函数

 

Windows.h中新的命名规范

类型	定义描述
WINAPI	使用在API声明中的FAR PASCAL位置，如果正在编写一个具有导出API人口点的DLL，则可以在自己的API中使用该类型
CALLBACK	使用在应用程序回叫例程，如窗口和对话框过程中的FAR PASCAL的位置
LPCSTR	与LPSTR相同，只是LPCSTR用于只读串指针，其定义类似（const char FAR*）
UINT	可移植的无符号整型类型，其大小由主机环境决定（对于Windows NT和Windows 9x为32位）；它是unsigned int的同义词
LRESULT	窗口程序返回值的类型
LPARAM	声明lParam所使用的类型，lParam是窗口程序的第四个参数
WPARAM	声明wParam所使用的类型，wParam是窗口程序的第三个参数
LPVOID	一般指针类型，与（void *）相同，可以用来代替LPSTR

 

    1.分层设计，隔离平台相关的代码。就像可测试性一样，可移植性也要从设计抓起。一般来说，最上层和最下层都不具有良好的可移植性。最上层是GUI，大多数GUI都不是跨平台的，如Win32 SDK和MFC。最下层是操作系统API，大多部分操作系统API都是专用的。

 

　　如果这两层的代码散布在整个软件中，那么这个软件的可植性将非常的差，这是不言自明的。那么如何避免这种情况呢？当然是分层设计了：

 

　　最底层采用Adapter模式，把不同操作系统的API封装成一套统一的接口。至于封装成类还是封装成函数，要看你采用的C还是C++写的程序了。这看起来很简单，其实不尽然（看完整篇文章后你会明白的），它将耗去你大量的时间去编写代码，去测试它们。采用现存的程序库，是明智的做法，有很多这样的库，比如，C库有glib（GNOME的基础类），C++库有ACE(ADAPTIVE Communication Environment)等等，在开发第一个平台时就采用这些库，可以大大减少移植的工作量。

 
- 程序结束释放

4另外还有一个专门放常量的地方。 - 程序结束释放在函数体中定义的变量通常是在栈上，用malloc, calloc, realloc等分配内存的函数分配得到的就是在堆上。在所有函数体外定义的是全局量，加了static修饰符后不管在哪里都存放在全局区（静态区）,在所有函数体外定义的static变量表示在该文件中有效，不能extern到别的文件用，在函数体内定义的static表示只在该函数体内有效。另外，函数中的"adgfdf"这样的字符串存放在常量区。

比如：

int a = 0; 全局初始化区
char *p1; 全局未初始化区
main()
{
int b; 栈
char s[] = "abc";栈
char *p2; 栈
char *p3 = "123456"; 123456在常量区，p3在栈上。
static int c =0； 全局（静态）初始化区
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
分配得来得10和20字节的区域就在堆区。
strcpy(p1, "123456"); 123456放在常量区，编译器可能会将它与p3所指向的"123456"优化成一块。
}