★ FEATURED ARTICLE 接手一个MFC老项目最先要过的往往不是业务逻辑而是命名这一关。头文件里密密麻麻的m_nCount、m_strUserName、m_pEditCtrl、hwnd、lParam新人看半天摸不着头脑老手瞟一眼却能大概猜出变量的类型和作用域。这套前缀规则就是Windows图形界面开发里流传多年的变量命名习惯俗称匈牙利命名法。它并不是把几个字母随便堆在变量名前面而是一套有逻辑、有层次、能直接在读代码时降低脑力负担的约定。这篇文章就把C和MFC环境里最常见的变量前缀完整梳理一遍从基础的类型前缀、作用域前缀到MFC控件相关的命名配方再到实际看代码时怎么利用前缀快速定位问题。不管你是刚接手老代码的新手还是想规范自己项目命名风格的开发者这份汇总都能直接拿来当速查手册。1. 前缀命名法的核心逻辑与判断思路搞懂前缀怎么用先要理解这套规则为什么存在。MFC的窗口类、对话框类通常有成百上千行代码成员变量一多变量到底是什么类型、在哪个作用域就成了读代码时最频繁的疑问。前缀就是把这个信息压缩进变量名本身让你第一眼就能做出判断省得每次翻定义。这套命名规则在Windows开发圈里流行了几十年主要有两条路线一条是系统匈牙利命名法用前缀表示变量的C类型比如iCount里的i代表int另一条是应用匈牙利命名法前缀表达的是变量的逻辑含义比如cchCount里的cch表示字符数的计数。MFC里大量使用的是前者把类型信息前置到变量名开头局部变量、函数参数、成员变量各有自己的写法组合起来就是一套完整的命名地图。判断一个变量名代表什么其实只需要两步。第一步看作用域前缀m_开头的是类的成员变量没有前缀的通常是局部变量或函数参数第二步看类型前缀n代表整数、str代表CString、p代表指针。两者叠加变量名就已经自我注释了。2. 常见前缀速查总表与分类解析2.1 基础类型前缀下面这张表是MFC代码里出现频率最高的一批基础类型前缀几乎每个C类里都会用到。整理的时候我按前缀 对应类型 示例的方式列出来方便直接对照查阅。前缀对应类型命名示例说明bBOOL / boolbVisible、bEnable在MFC中BOOL本质是intbool是C布尔类型两者混用时要小心byBYTEbyMask无符号字符型处理字节流时常用ccharcKey单个字符用于遍历字符串、处理输入时wwchar_t / WORDwChar宽字符或16位无符号整数看语境判断nint / UINTnCount、nIndex数量、索引、状态码Windows代码里最勤快的成员iintiLoop与n作用相同偏循环或下标场景llong / LPARAMlOffset、lParam32位长整数注意LPARAM是平台相关的lllong long / __int64llTimestamp大整数存时间戳、超大计数值uunsigned intuThreadId无符号整数dwDWORDdwStyle、dwFlags32位无符号整数存标志位、样式值ffloat / BOOLfRatio、fReady见到f先是浮点还是布尔参考所在类上下文ddoubledPrecision双精度浮点ftFILETIMEftLastWriteWindows文件时间结构体rRECT / CRectrClient矩形区域ptPOINT / CPointptOrigin二维坐标点szC风格字符串数组szFileName以空字符结尾的字符串来自zero-terminated stringstrCStringstrNameMFC项目最常用的字符串类型bstrBSTRbstrTextCOM自动化场景的字符串类型p指针任意类型pDoc、pWnd指针类型的通用前缀lp长指针lpData32位平台下与p等价老代码里残留lpsz指向C风格字符串的指针lpszCmdLine长指针指向零结尾字符串的缩写h句柄hWnd、hDC、hInstanceWindows核心资源标识pfn函数指针pfnCallback回调函数入口fn函数fnCompare偶尔见到表示函数对象或函数引用a数组aBuffer配合类型使用如aBytet / tm时间结构tmCreate存时间字段比如struct tm别被p、lp、lpsz这种老式前缀吓到。MFC的代码库承袭了Windows API几十年的演进底层API用lpCreateStruct、lpszClassName这种写法上头MFC封装后的类成员却喜欢用m_pWnd、m_strText这种更简洁的写法。你看代码时只要知道lp和p本质都是指针lpsz就是指针加字符串sz本身就是字符数组不需要区分得过于痛苦。2.2 作用域前缀作用域前缀回答的是这个变量属于谁。这是MFC项目里最实用、最容易形成肌肉记忆的一类前缀。前缀作用域命名示例使用场景m_类的成员变量m_nMaxCount、m_strUserName在所有类成员变量里出现包括控件变量g_全局变量g_bAppRunning跨模块共享状态MFC项目中应尽量少用s_静态变量s_pInstance静态成员常用于单例、全局回调里传递上下文c_常量类内c_nMaxBuffer类的编译期常量或只读变量(无)局部变量nTemp、strTemp函数内部临时变量、循环变量k常量全局风格kMaxBufferSize部分团队偏好global const的写法m_是这个清单里最重要的前缀。它存在的核心价值是区分成员变量和局部变量。MFC的类成员函数往往很长一个对话框函数里既操作成员变量又创建临时变量如果都裸写后期维护根本分不清哪一个是类的持久状态、哪一个是这次调用里用一下就扔的临时数据。m_前缀直接避免了这个混淆。此外MFC的IDD/IDC这类标识符不算严格的前缀但你必须认识它们前缀含义示例IDD_对话框资源IDIDD_LOGIN_DIALOGIDC_控件IDIDC_EDIT_USERNAME、IDC_BTN_LOGINIDR_菜单/工具栏/加速键资源IDIDR_MAINFRAMEIDS_字符串资源IDIDS_APP_TITLEIDB_位图资源IDIDB_HEADER_IMAGEIDM_菜单IDIDM_FILE_OPENIDI_图标IDIDI_MAIN_ICONAFX_MFC框架定义AFX_IDW_PANE_FIRST资源ID前缀在上位机界面项目、传统桌面工具软件里最有存在感。你打开一个资源文件看到IDD_开头就知道这是个对话框IDC_开头就是个控件不需要去查资源类型命名本身就完成了分类。这套命名还直接影响MFC的DDX/DDV机制写DDX_Text(pDX, IDC_EDIT_NAME, m_strName)时如果控件ID不遵循IDC_规范代码的自我文档化程度会大打折扣。3. MFC场景下的命名实操配方只认前缀还不够MFC项目里不同场景的命名组合是有固定配方的。我把最常见的几种场景分别展开你看完可以直接套用。3.1 类的成员变量命名MFC窗口类、对话框类、文档类里成员变量命名通常采用m_ 类型前缀 有意义的名称的组合方式。类型前缀首字母保持小写后面的业务含义首字母大写单词之间不推荐用下划线隔开。class CMainDialog : public CDialogEx { private: int m_nCurrentIndex; // 当前选中项的索引 CString m_strInputText; // 输入框文本 BOOL m_bSaveFlag; // 是否保存的标志 CEdit m_editName; // 姓名输入框控件 CButton m_btnLogin; // 登录按钮控件 CListCtrl m_listResult; // 结果列表控件 CBrush m_brBackground; // 背景画刷 CFont m_fontTitle; // 标题字体 std::vectorItemInfo* m_vecItemList; // 数据项指针列表 double m_dThreshold; // 判定阈值 DWORD m_dwLastClickTime; // 最近一次点击的时间戳 };这个命名配方看起来简单实际上的好处要等代码量上来才体会得到。比如你在OnBnClickedBtnLogin里突然看到一行m_strInputText不需要翻头文件就能确认它是成员变量、CString类型如果你看到nLen立刻知道这是函数里的临时量。读代码变成了扫一眼名字、直接理解逻辑的流程而不是看到一个变量、停下来查定义的打断式体验。成员变量命名最怕的是只写业务含义、丢掉类型前缀。比如m_Username、m_Count这类写法虽然能看懂业务含义但类型不明。m_Count是int还是DWORDm_Username是CString还是std::string每次用到都心存疑虑跨函数传参时还得回去查声明。加一个字母的成本换来的是每次读代码节省数秒钟的查证时间这在几万行的项目里收益是复利式的。还有一类控件关联成员变量需要单独留意。使用类向导添加控件变量时MFC默认生成的是m_editName、m_btnLogin这种以控件类型缩写作前缀的写法。这时m_editName里的edit表示CEdit类型的控件变量m_btnLogin里的btn表示CButton类型的控件变量与前面的基础类型前缀体系略有不同但思路完全一致用开头两三个字母标注类型。3.2 局部变量与函数参数命名函数体内的局部变量传统写法是在类型前缀后直接跟上业务含义不再加m_。参数变量也类似但很多老代码习惯在参数前加p表示指针或者直接让类型前缀充当参数名的前半段。void CMainDialog::OnBnClickedLogin() { CString strUserName; CString strPassword; GetDlgItemText(IDC_EDIT_USERNAME, strUserName); GetDlgItemText(IDC_EDIT_PASSWORD, strPassword); int nRet CheckUserInput(strUserName, strPassword); if (nRet 0) { AfxMessageBox(_T(输入不合法)); return; } BOOL bSuccess m_userService.Login(strUserName, strPassword); if (!bSuccess) { AfxMessageBox(_T(登录失败)); return; } LPCTSTR lpszMsg GetTipMessage(); SetDlgItemText(IDC_STATIC_TIP, lpszMsg); }局部变量无前缀是MFC代码最常见的风格但这不代表局部变量可以乱起名。团队协作里见过不少新人把局部变量一律叫temp、flag这种名字虽然带上了t、f前缀含义却完全缺失。好的局部变量名应当同时满足信息量和简洁性strUserName告诉你它是CString且内容是用户名nRet告诉你它是一个整型返回值bSuccess告诉你它是一个布尔成功标志。三五个字母的前缀承载了类型、作用域、业务语义三层信息。函数参数的命名有一点传统值得尊重当参数是一个指针时加p前缀是共识。有些团队甚至约定参数用p_开头如p_editCtrl_但这在Windows原生风格里相对少见沿用pWnd、pDlg、pView这一路更贴合MFC的语境。3.3 句柄、指针与MFC封装对象的命名MFC里有两套表达资源引用的方式一套是赤裸的Windows句柄另一套是MFC封装类。它们分别有自己的命名偏好。Windows句柄类型的变量名传统上直接采用h 对象缩写的格式而且h后的字母通常不再大写形成hWnd、hDC、hBtn这种连续小写的风格这是从Win32 API时代继承下来的惯例。比如写一个绘图函数hdcMem、hBitmap、hBrush就是标准写法HDC hdc ::GetDC(m_hWnd); HDC hdcMem ::CreateCompatibleDC(hdc); HBITMAP hbmMem ::CreateCompatibleBitmap(hdc, cx, cy); HGDIOBJ hOldBitmap ::SelectObject(hdcMem, hbmMem); // 绘制流程... ::SelectObject(hdcMem, hOldBitmap); ::DeleteDC(hdcMem); ::ReleaseDC(m_hWnd, hdc);MFC封装类对象的命名则走另一条路。CButton、CEdit、CListCtrl、CPen、CBrush这些封装类实例常用m_btnX、m_editX、m_listX、pen、brush这样的名字有时也会直接以类型名的小写形态出现。这不算违反规则因为MFC对象在堆栈上使用、生命周期受作用域控制取名更看重业务属性而非类型区分。这里最容易踩坑的是句柄和封装类的混用一个项目里既写了m_hWnd又写了m_pWnd前者是HWND裸句柄后者是CWnd指针。两者都能调用窗口相关API但一个用::前缀一个用-写混了编译期不一定报错运行期大概率出问题。所以命名时务必把h和p严格区分看到m_hWnd就该知道要调用Win32 API看到m_pWnd就该走MFC封装接口。3.4 消息处理函数与事件相关参数MFC的消息处理函数里参数名前缀有两类高频写法。一类是框架生成的wParam、lParam来自Windows消息结构w表示WORD16位演变来的参数l表示LONG参数虽然View模式里它们都是WPARAM/LPARAM类型但名字保留了几十年前的字面含义。另一类是MFC封装后生成的参数比如NMHDR* pNMHDR, LRESULT* pResult前缀p指向通知头结构体和返回值指针。自定义消息处理函数时保留这套写法能让代码库保持一致LRESULT CMainDialog::OnMyMessage(WPARAM wParam, LPARAM lParam) { // wParam用于传递小整数或窗口句柄lParam用于传递指针或复合数据 int nParam (int)wParam; MyStruct* pData (MyStruct*)lParam; // 处理逻辑... return 0; }在消息处理函数里不推荐自创一套变量名来替代wParam/lParam因为MFC框架和阅读者对这两个名字有天然共识。你可以用局部变量把它们转成有业务含义的类型但入口参数名保持约定俗成的写法协作成本最低。4. 前缀命名与代码维护的实战心得4.1 新代码与老代码的前缀冲突我维护过一个历史项目底层Win32风格浓厚到处是lpszText、dwRet、hbrOld上层MFC对话框又全是m_strName、m_nValue、m_ctrlList。两个风格并存并不难读因为前缀已经足够表达信息凡是lpsz、dw、h开头的按Win32语义理解凡是m_开头的按MFC类成员理解。真正麻烦的是同一词在不同年代可能有不同含义。比如b前缀老代码里清一色表示BOOL新代码可能用来表示 C 的bool。Windows的BOOL是int的typedefbool是真布尔两者都叫b前缀只是类型体系不同。我的建议是在新代码里统一用一种老代码保持原样不要顺手修正修正过程中引入的错误往往比命名不规范造成的困扰更严重。4.2 命名前缀争议的正确态度频繁听到一种观点匈牙利命名法已经过时了现代C讲究类型安全变量名里标注类型是冗余。这个说法有道理但放到MFC场景里并不完全成立。MFC的上下文决定了对变量名带类型信息有刚需控件变量、句柄、GDI对象、COM指针、CString与std::string共存类型关系复杂得很。现代C的auto推导再好阅读代码时仍然需要在脑子里把类型还原出来。前缀法相当于一种牺牲少量打字成本、换取读码速度的折中方案在老项目和遗留系统里这个折中至今依然划算。我自己的立场是不用全盘照搬旧约但要尊重一套已经跑通的规则。接手老项目先按既有前缀规范写新代码新建项目团队内部定一份简洁的前缀表白纸黑字写清楚执行时宁缺毋滥也比完全没有规范强。4.3 常见命名混乱与排查技巧MFC项目里命名混乱集中在这么几类情况m_pWnd和m_hWnd混淆使用。排查时认准m_hWnd是HWND出现在::GetWindowRect、::SendMessage这类API调用里m_pWnd是CWnd指针出现在GetDlgItem、SetWindowText这类MFC方法调用链里。两者都能做很多相同的操作但混用特别容易出现窗口句柄有效、却无法正常调MFC方法的诡异现象。str前缀的变量到底是CString还是std::string。CString可以直接处理中文和_T宏std::string遇到宽字符要另想办法。命名规范里最好明确项目里str只对应CStringstd::string用stdStr或s单独约定避免再猜。布尔变量用n还是b。写了nFlag的老代码实际上是int按非0/0判断如果后来改成bFlag却是bool两者混用时容易出现bFlag nFlag ! 0的转换疏漏。排查时优先看使用时是if (nFlag)还是if (nFlag ! 0)前者说明按Bool语义对待后者说明按int语义处理前缀和实际用法的偏差往往就是bug来源。资源ID与控件变量弄混。IDC_EDIT_NAME是资源IDm_editName是控件变量两者名字里都有Name极容易写串。记一条铁律资源ID永远出现在DDX_、GetDlgItem、SetDlgItemText等函数的第一个或者资源参数位置带IDC_前缀控件变量永远出现在资源ID后面带m_或类型缩前前缀。写反了编译能过运行期拿到的要么是空窗口、要么是无效资源句柄半天查不出来。4.4 排查遗留代码时的前缀速读法读一段完全陌生的MFC代码时我习惯先按前缀分类再追踪逻辑。第一步把每个变量的前缀抄下来分类第二步按作用域—类型—业务含义三层还原它的真实身份第三步再进入逻辑追踪。举个例子看到一行m_dwStyle | WS_VISIBLE立刻知道m_dwStyle是一个成员DWORD用来存窗口扩展样式。看到lParam被强转成MyStruct*立刻知道这是自定义消息在传结构体指针。看到nRet 0知道返回值是负值代表错误的传统做法。这些信息不是靠阅读函数体外的一段逻辑推理出来的而是前缀直接告诉你的。对于报错定位场景前缀法还能加速查找。比如编译报错提示某个strText符号不明确你在函数体里找到strText发现它是在循环里被反复赋值的临时CString那么问题大概率出在作用域遮蔽或者变量重用上如果它有m_前缀那就要去检查这个成员是不是被多个线程或多次消息处理过程并发修改。名字带上了作用域和类型信息定位路径一下子就缩短了。5. 我在实际开发中的个人经验说几句很实际的体会。我见过太多新人在MFC项目里为了看起来现代把成员变量一律省略m_结果类里局部变量和成员变量混在一起改了局部变量没改成员变量排查bug花了一个下午。也见过老手把m_p和m_h分得清清楚楚在问题爆发前就避免了一大类窗口资源操作错误。我现在的习惯是无论新老项目进手先读一遍该项目的命名规范或者至少花半小时把现有代码里的前缀规律摸一遍。摸清之后写新代码严格沿用它改旧代码尽量不改变量名只改逻辑。这样做的代价是最小的而收益会随着代码库的增长越来越明显——你不再需要反复查定义就能顺畅读代码也不再需要问同事这个变量是什么类型。如果你刚接触MFC项目我建议你把这篇文章里的前缀表打印一份放在手边花一周时间刻意地读前缀、猜类型、验定义一周后你会发现读代码速度快了一大截。这套做法不神秘不酷炫但它是几十万Windows桌面项目验证过的信息组织方式实用得很。
阅读完成 · 觉得有帮助？
