编程5分钟，命名2小时！大神程序员都在用这套命名方法

在 软件中随处可见命名：要给变量、函数、参数、类和封包命名，还要给源代码及源代码所在目录命名，甚至还有jar文件、war文件和ear文件命名。

但是，看似简单的命名，也是让不少程序员头疼的问题。 有一些小伙伴，在进行变量命名的时候，对于自己熟悉的英文，可能还会用英文命名一下，如果需要命名的部分不会用英文表达，或许就直接用拼音了。

有的童鞋一下想不起来怎么命名，直接用拼音直接用aa，bb等这样没有任何代表意义的字母来命名，可读性非常差，可能自己今天写的，一个星期后回来再看，也忘记其具体代表的含义了。

因此，许多人在写代码之前，总会在想啊想啊，用什么命名法好呢？对于经常在C++、Java、Python等主流语言上切换的强迫症来说，换个语言换种命名风格简直不要太混乱。

既然有这么多命名要做，不妨做好它。本期内容中，异步君为大家带来了起个好名字应遵从的几条简单规则，一起来看看吧

— 01 —

名副其实

名副其实说起来简单。我们想要强调，这事很严肃。选个好名字要花时间，但省下来的时间比花掉的多。注意命名，而且一旦发现有更好的名称，就换掉旧的。这么做，读你代码的人（包括你自己）都会更开心。

变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。

名称d什么也没说明。它没有引起读者对时间消逝的感觉，更别说以日计了。我们应该选择指明了计量对象和计量单位的名称：

选择体现本意的名称能让人更容易理解和修改代码。下列代码的目的何在？

为什么难以说明上述代码要做什么事？里面并没有复杂的表达式，空格和缩进中规中矩，只用到三个变量和两个常量，甚至没有涉及任何其他类或多态方法，只是（或者看起来是）一个数组的列表而已。

问题不在于代码的简洁度，而在于代码的模糊度：即上下文在代码中未被明确体现的程度。上述代码要求我们了解类似以下问题的答案：

（1）theList中是什么类型的东西？

（2）theList零下标条目的意义是什么？

（3）值4的意义是什么？

（4）我怎么使用返回的列表？

问题的答案没体现在代码段中，可代码段就是它们该在的地方。比方说，我们在开发一种扫雷 游戏 ，我们发现，盘面是名为theList的单元格列表，那就将其名称改为gameBoard。

盘面上每个单元格都用一个简单数组表示。我们还发现，零下标条目是一种状态值，而该种状态值为4表示“已标记”。只要改为有意义的名称，代码就会得到相当程度的改进：

注意，代码的简洁性并未被触及。运算符和常量的数量全然保持不变，嵌套数量也全然保持不变，但代码变得明确多了。

还可以更进一步，不用int数组表示单元格，而是另写一个类。该类包括一个名副其实的函数（称为isFlagged），从而掩盖住那个魔术数[1]。于是得到函数的新版本：

只要简单改一下名称，就能轻易知道发生了什么。这就是选用好名称的力量。

— 02 —

避免误导

程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词，例如，hp、aix和sco都不该用作变量名，因为它们都是Unix平台或类Unix平台的专有名称。即便你是在编写三角计算程序，hp看起来是一个不错的缩写[2]，但那也可能会提供错误信息。

别用accountList来指称一组账号，除非它真的是List类型。List一词对程序员有特殊意义。如果包纳账号的容器并非真是一个List，就会引起错误的判断。

所以，用accountGroup或bunchOfAccounts，甚至直接用accounts都会好一些。

提防使用外形相似度较高的名称。例如，想区分模块中某处的XYZControllerFor-EfficientHandlingOfStrings和另一处的XYZControllerForEfficientStorage-OfStrings，会花多长时间呢？这两个词的外形实在太相似了。

以同样的方式拼写出同样的概念才是信息。拼写前后不一致就是误导。我们很享受现代Java编程环境的自动代码完成特性。键入某个名称的前几个字母，按一下某个热键组合（如果有的话），就能得到一列该名称的可能形式。

假如相似的名称依字母顺序放在一起，且差异很明显，那就会相当有助益，因为程序员多半会压根不看你的详细注释，甚至不看该类的方法列表就直接看名字挑一个对象。

误导性名称真正可怕的例子，是用小写字母l和大写字母O作为变量名，尤其是在组合使用的时候。当然，问题在于它们看起来完全像是常量“壹”和“零”。

读者可能会认为这纯属虚构，但我们确曾见过充斥这类名称的代码。有一次，代码作者建议用不同字体写变量名，好显得更清楚些，但前提是这种方案得要通过口头和书面传递给未来所有的开发者才行。后来，只是做了简单的重命名 *** 作，就解决了问题，而且也没引起别的问题。

— 03 —

做有意义的区分

如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。例如，因为同一作用范围内两样不同的东西不能重名，你可能会随手改掉其中一个的名称，有时干脆以错误的拼写充数，结果就会出现在更正拼写错误后导致编译器出错的情况。

光是添加数字系列或是废话远远不够，即便这足以让编译器满意。如果名称必须相异，那么其意思也应该不同才对。

以数字系列命名（a1、a2…aN）是依义命名的对立面。这样的名称纯属误导——完全没有提供正确信息，没有提供导向作者意图的线索。试看：

如果参数名改为source和destination，这个函数就会像样许多。

废话是另一种没意义的区分。假设你有一个Product类，如果还有一个名为ProductInfo或ProductData的类，那它们的名称虽然不同，意思却无区别。Info和Data就像a、an和the一样，是意义含混的废话。

注意，只要体现出有意义的区分，使用a和the这样的前缀就没错。例如，你可能把a用在域内变量，而把the用于函数参数[5]。但如果你已经有一个名为zork的变量，又想调用一个名为theZork的变量，麻烦就来了。

废话都是冗余。variable一词永远不应当出现在变量名中。table一词永远不应当出现在表名中。NameString会比Name好吗？难道Name会是一个浮点数？如果是这样，就违反了关于误导的规则。

设想有一个名为Customer的类，还有一个名为CustomerObject的类，它们的区别何在呢？哪一个是表示客户 历史 支付情况的最佳方式？

有一个应用反映了这种状况。为当事者讳，我们改了一下，不过犯错的代码的确就是这个样子：

程序员怎么知道该调用哪个函数呢？

如果缺少明确约定，那么变量moneyAmount与money就没区别，customerInfo与customer没区别，accountData与account没区别，theMessage也与message没区别。要区分名称，就要以读者能鉴别不同之处的方式来区分。

— 04 —

使用读得出来的名称

人类长于记忆和使用单词。大脑的相当一部分就是用来容纳和处理单词的。单词能读得出来。人类的大脑中有那么大的一块地方用来处理言语，若不善加利用，实在是种耻辱。

如果名称读不出来，讨论的时候就会像个傻鸟。“哎，这儿，鼻涕阿三喜摁踢（bee cee arr three cee enn tee）[6]上头，有个皮挨死极翘（pee ess zee kyew）[7]整数，看见没？”这不是小事，因为编程本就是一种 社会 活动。

有一家公司，程序里面写了一个genymdhms（生成日期，年、月、日、时、分、秒），他们一般读作“gen why emm dee aich emm ess”[8]。我有见字照拼读的恶习，于是开口就念“gen-yah-mudda-hims”。

后来好些设计师和分析师都有样学样，听起来傻乎乎的。我们知道典故，所以会觉得很 搞笑 。 搞笑 归 搞笑 ，实际是在强忍糟糕的命名。在给新开发者解释变量名的意义时，他们总是读出傻乎乎的自造词，而非恰当的英语词。比较

现在读起来就像人话了：“喂，Mikey，看看这条记录！生成时间戳（generation timestamp）[9]被设置为明天了！不能这样吧？”

— 05 —

使用可搜索的名称

对于单字母名称和数字常量，有一个问题，就是很难在一大篇文字中找出来。

找MAX_CLASSES_PER_STUDENT很容易，但想找数字7就麻烦了，它可能是某些文件名或其他常量定义的一部分，出现在因不同意图而采用的各种表达式中。如果该常量是个长数字，又被人错改过，就会逃过搜索，从而造成错误。

同样，e也不是一个便于搜索的好变量名，它是英文中最常用的字母，在每个程序、每段代码中都有可能出现。由此而见，长名称胜于短名称，搜得到的名称胜于用自造编码代写就的名称。

窃以为单字母名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应 [N5]。若变量或常量可能在代码中多处使用，则应赋予其便于搜索的名称。再比较：

注意，上面代码中的sum并非特别有用的名称，不过至少搜得到它。采用能表达意图的名称，貌似拉长了函数代码，但要想想看，WORK_DAYS_PER_WEEK比数字5好找得多，而列表中也只剩下了体现作者意图的名称。

— 06 —

避免使用编码

编码已经太多，无谓再自找麻烦。把类型或作用域编进名称里面，徒然增加了解码的负担。没理由要求每位新人都在弄清要应付的代码之外（那算是正常的），还要再搞懂另一种编码“语言”。这对解决问题而言，纯属多余的负担。带编码的名称通常也不便发音，容易打错。

匈牙利语标记法

在往昔名称长短很重要的时代，我们毫无必要地破坏了不编码的规矩，如今后悔不迭。Fortran语言要求首字母体现出类型，导致了编码的产生。BASIC语言的早期版本只允许使用一个字母再加上一位数字。匈牙利语标记法[10]（Hungarian Notation，HN）将这种态势愈演愈烈。

在Windows的C语言API的时代，HN相当重要，那时所有名称要么是一个整数句柄，要么是一个长指针或者void指针，要不然就是string的几种实现（有不同的用途和属性）之一。那时候编译器并不做类型检查，程序员需要匈牙利语标记法来帮助自己记住类型。

现代编程语言具有更丰富的类型系统，编译器也记得并强制使用类型。而且，程序员趋向于使用更小的类、更短的方法，好让每个变量的定义都在视野范围之内。

Java程序员不需要类型编码，因为对象是强类型的，代码编辑环境已经先进到在编译开始前就能监测到类型错误的程度！所以，如今HN和其他的类型编码形式都纯属多余。它们增加了修改变量、函数或类的名称或类型的难度，它们增加了阅读代码的难度，它们制造了让编码系统误导读者的可能性。

成员前缀

也不必用m_前缀来标明成员变量。应当把类和函数做得足够小，以消除对成员前缀的需要。你应当使用某种可以高亮或用颜色标出成员的编辑环境。

此外，人们会很快学会无视前缀（或后缀），而只看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。

接口和实现

有时也会出现采用编码的特殊情形。比如，你在做一个创建形状用的抽象工厂（Abstract Factory），该工厂是一个接口，要用具体类来实现。你怎么来命名工厂和具体类呢？IShapeFactory和ShapeFactory吗？我喜欢不加修饰的接口。前导字母I被滥用到了说好听点儿是干扰，说难听点儿根本就是废话的程度。

我不想让用户知道我给他们的是接口，而就想让他们知道那是一个ShapeFactory。如果在接口和实现中必须选其一来编码的话，我宁肯选择实现。ShapeFactoryImp，甚至是丑陋的CShapeFactory，都比对接口名称编码好。

-END-

代码整洁之道

作者： [美] 罗伯特·C 马丁（Robert C Martin）

译者： 韩磊

内容简介：

软件质量，不但依赖架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。

本书提出一种观点：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，本书作者给出了一系列行之有效的整洁代码 *** 作实践。这些实践在本书中体现为一条条规则（或称“启示”），并辅以来自实际项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。

本书阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。

变量的命名规则遵循 Camel 命名法，并尽量使用能描述变量作用的英文单词。例如存放学生姓名的变量可以定义成 name 或者 studentName 等。另外，变量名字也不建议过长， 最好是 1 个单词，最多不超过 3 个单词。

标识符的命名规则如下：标识符可由三类字符：字母、下划线、数字组成；标识符只能由字母或下划线开头；标识符不能具有二义性；标识符有长度要求，在起定的名字中!超出长度规定的部分将被截掉。

变量命名的规则如下：

①变量名区分字母的大小写，因此B与b表示的是不同的变量。

②变量名只能由字母、数字和下划线组成，且必须以英文字母开头。例如：b，b1，b1a都是合法的，而1b，b，b2，{b}都是不合法的。

③变量名长度不得超过最大长度限制，超过的部分将被忽略。不同的MATLAB版本，变量的最大长度限制是不同的，用户可以使用 namelengthmax函数得到该用户使用的 MATLAB版本所规定的变量名长度。

④关键字(如for、end和if等)不能作为变量名。常量是指那些在 MATLAB中已预先定义其数值的变量，也称预定义变量。变量命名时应尽量避开这些预定义变量。

排序不等式是：倒序<=乱序<=顺序；所以最好是a和b都排序成顺序才会得到最大值。但如果a保持不动，让b排序使得得到的乘积最大，这其实是一个整数二元线性规划问题。你可以设一个矩阵c，这个矩阵是7x7的，行元素表示对应a中1到7的位置，列元素的含义是对应b元素不排序的值。在7x7矩阵中aij表示：a中从头开始第i个元素与b中从头开始第j个元素相对应，则在此处取值为1，否则取值为零。而7x7矩阵每一行求和为1，每一列求和为1。这样只有求解max（ca）就ok。解决这样的二元整数规划，你可以尝试使用匈牙利算法，或者直接使用lingo或者matlab求解。这属于运筹学问题。

Package 的命名 Package 的名字应该都是由一个小写单词组成。 Class 的命名 Class 的名字必须由大写字母开头而其他字母都小写的单词组成 Class 变量的命名 变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。 Static Final 变量的命

一般来讲MATLAB里变量命名并没有这样的习惯

如果你看到的变量很多是大写字母, 那么比较有可能是这些都是真正的矩阵(不是向量和标量的矩阵), 在线性代数里常用大写拉丁字母表示, 在程序里也就这样表示

匈牙利命名法

匈牙利命名法是一种编程时的命名规范。基本原则是：变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确含义，可以取对象名字全称或名字的一部分。命名要基于容易记忆容易理解的原则。保证名字的连贯性是非常重要的。

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

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

属性部分

全局变量

g_

常量

c_

c++类成员变量

m_

静态变量

s_

类型部分

指针

p

函数

fn

无效

v

句柄

h

长整型

l

布尔

b

浮点型（有时也指文件）

f

双字

dw

字符串

sz

短整型

n

双精度浮点

d

计数

c（通常用cnt）

字符

ch（通常用c）

整型

i（通常用n）

字节

by

字

w

实型

r

无符号

u

描述部分

最大

Max

最小

Min

初始化

Init

临时变量

T（或Temp）

源对象

Src

目的对象

Dest

这里顺便写几个例子：

hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄；

pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示

指向 EatApple 函数的函数指针变量。

g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类

型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。

上面就是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 = 调试；忽略标识符为发行。

静态库版本命名规范 库 描述

NAFXCWDLIB 调试版本：MFC静态连接库

NAFXCWLIB 发行版本：MFC静态连接库

UAFXCWDLIB 调试版本：具有Unicode支持的MFC静态连接库

UAFXCWLIB 发行版本：具有Unicode支持的MFC静态连接库

动态连接库命名规范 名称 类型

_AFXDLL 唯一的动态连接库（DLL）版本

WINAPI Windows所提供的函数

Windowsh中新的命名规范 类型 定义描述

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

--------------------------------------------------------------------------------

抨击匈牙利命名法

匈牙利命名法是一种编程时的命名规范。命名规范是程序书写规范中最重要也是最富争议的地方，自古乃兵家必争之地。命名规范有何用？四个字：名正言顺。用二分法，命名规范分为好的命名规范和坏的命名规范，也就是说名正言顺的命名规范和名不正言不顺的命名规范。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。一个坏的命名规范具有的破坏力比一个好的命名规范具有的创造力要大得多。

本文要证明的是：匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为C语言和C++语言。下文中的匈法为匈牙利命名法的简称。

一 匈牙利命名法的成本

匈法的表现形式为给变量名附加上类型名前缀，例如：nFoo,szFoo,pFoo,cpFoo分别表示整型变量，字符串型变量，指针型变量和常指针型变量。可以看出，匈法将变量的类型信息从单一地点（声明变量处）复制到了多个地点（使用变量处），这是冗余法。冗余法的成本之一是要维护副本的一致性。这个成本在编写和维护代码的过程中需要改变变量的类型时付出。冗余法的成本之二是占用了额外的空间。一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位的长度以30个自然行以下为宜，如果超过50行就应该重新组织。一个变量的书写空间会给这一法则添加不必要的难度。

二 匈牙利命名法的收益

这里要证明匈牙利命名法的收益是含糊的，无法预期的。

范本1：strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)

匈法在这里有什么收益呢？我看不到。没有一个程序员会承认自己不知道strcpy函数的参数类型吧。

范本2：unknown_function(nFoo) Vs unknown_function(foo)

匈法在这里有什么收益呢？我看不到。对于一个不知道确定类型的函数，程序员应该去查看该函数的文档，这是一种成本。使用匈法的唯一好处是看代码的人知道这个函数要求一个整型参数，这又有什么用处呢？函数是一种接口，参数的类型仅仅是接口中的一小部分。诸如函数的功能、出口信息、线程安全性、异常安全性、参数合法性等重要信息还是必须查阅文档。

范本3：nFoo=nBar Vs foo=bar

匈法在这里有什么收益呢？我看不到。使用匈法的唯一好处是看代码的人知道这里发生了一个整型变量的复制动作，听起来没什么问题，可以安心睡大觉了。如果他看到的是nFoo=szBar，可能会从美梦中惊醒。且慢，事情真的会是这样吗？我想首先被惊醒的应该是编译器。另一方面，nFoo=nBar只是在语法上合法而已，看代码的人真正关心的是语义的合法性，匈法对此毫无帮助。另一方面，一个优秀的书写者会自觉地遵从一个法则：代码最小组织单位中的临时变量以一两个为宜，如果超过三个就应该重新组织。结合前述第一个法则，可以得出这样的结论：易于理解的代码本身就应该是易于理解的，这是代码的内建高质量。好的命名规范对内建高质量的助益相当有限，而坏的命名规范对内建高质量的损害比人们想象的要大。

三 匈牙利命名法的实施

这里要证明匈牙利命名法在C语言是难以实施的，在C++语言中是无法实施的。从逻辑上讲，对匈法的收益做出否定的结论以后，再来论证匈法的可行性，是画蛇添足。不过有鉴于小马哥曾让已射杀之敌死灰复燃，我还是再踏上一支脚为妙。

前面讲过，匈法是类型系统的冗余，所以实施匈法的关键是我们是否能够精确地对类型系统进行复制。这取决于类型系统的复杂性。

先来看看C语言：

1内置类型：int,char,float,double 复制为 n,ch,f,d？好像没有什么问题。不过谁来告诉我void应该怎么表示？

2组合类型：array,union,enum,struct 复制为 a,u,e,s？好像比较别扭。

这里的难点不是为主类型取名，而是为副类型取名。an表示整型数组？sfoo,sbar表示结构foo，结构bar？ausfoo表示联合结构foo数组？累不累啊。

3特殊类型：pointer。pointer在理论上应该是组合类型，但是在C语言中可以认为是内置类型，因为C语言并没有非常严格地区分不同的指针类型。下面开始表演：pausfoo表示联合结构foo数组指针？ppp表示指针的指针的指针？

噩梦还没有结束，再来看看类型系统更阿为丰富的C++语言：

1class：如果说C语言中的struct还可以用stru搪塞过去的话，不要梦想用cls来搪塞C++中的class。严格地讲，class根本就并不是一个类型，而是创造类型的工具，在C++中，语言内置类型的数量和class创造的用户自定义类型的数量相比完全可以忽略不计。stdvectorFoo表示标准库向量类型变量Foo？疯狂的念头。

2命名空间：boostfilesystemiteratorFoo，表示boost空间filesystem子空间遍历目录类型变量Foo？程序员要崩溃了。

3模板：你记得std::map<std::string,std::string>类型的确切名字吗？我是记不得了，好像超过255个字符，还是饶了我吧。

4模板参数：template <class T, class BinaryPredicate>const T& max(const T& a, const T& b, BinaryPredicate comp) 聪明的你，请用匈法为T命名。上帝在发笑。

5类型修饰：static,extern,mutable,register,volatile,const,short,long,unsigned 噩梦加上修饰是什么？还是噩梦。百度地图

以上就是关于编程5分钟，命名2小时！大神程序员都在用这套命名方法全部的内容，包括:编程5分钟，命名2小时！大神程序员都在用这套命名方法、变量的命名规则、matlab 怎样定义一个数组，它的每个元素是一个向量，且向量长度不等等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！