代码如诗之变量命名

BruceWolf

文中只是个人习惯，即使对个人来说亦不是铁律，我自己在代码过程中也会视具体情况变通。我的 php 学习都是基于 php v5 以上版本，所以会造成一些片面的观点，如文中所述有不正确之处，还望多多提点。发布于此，只希望能对大家有些许帮助。

废话完毕，上菜！

---------

代码如诗之变量命名

一、变量名的意义

变量是代码的重要组成元素，有效的命名规则会让代码阅读的阅读效率更高，不论是别人阅读，还是三十天后的自己来阅读。Debug 也是基于代码阅读效率之上。

有些变量命名的规则会导致对变量本身的过多关注或者对变量的理解花费过多精力而影响代码阅读效率，在一定程度也影响 debug 的效率。

代码本身就是文档，良好的代码在没有代码注释或者代码注释很少的情况下依然能被快速阅读、理解，良好的命名规范是这种转变的重要组成部分。需要命名的除了变量还有函数、类、方法等等，在这里只讨论变量名的命名方法，权当抛砖引玉。

二、命名规则

1. 驼峰命名

减少视野跨度，降低对变量名本身的关注，有利于强化对信息的提取而不打断对阅读代码时思维的连贯性:

$firstBookTitle vs $first_book_title

后者会引导代码阅读者去潜意识设置语言断点、过度强调变量名的各个词的含义，而对于代码阅的，我们需要的是一个清晰的“标记”去标识一个内容，这个标记就是识别内容的最小单元。一个变量名就是一份数据内容的标记，看见这个标记，在赋值时能了解到其大致内容，调用时能联想到其大致内容形式和上次出现的地方就足够了。

2. 使用后缀

适当使用后缀，只对字符串和数组用后缀，Str、Arr。比如：

$lunchOrdersStr : 点餐的名字列表

$lunchOrdersArr : 转化为数组的名字清单

从代码的整体阅读来看，变量的内容比其数据结构更具重要性，所以不使用类型的前缀标识（匈牙利命名法），而使用后缀。使用后缀也只是在小区域出现大量类似内容集中出现才使用，一般不要使用。比如刚才的变量名一般只出现在以下场景：

$lunchOrdersArr= explode(',',$lunchOrdersStr);

3. 采用实意命名

通过变量名的语义来体现变量的数据类型和内容：

$articleCount: integer，Count结尾

$entries:array，复数形式

资源类型的变量，可以参照 php 手册的风格，使用具有实意的变量名：

文件句柄：$handle

数据库连接：$link

Socket连接：$sock

杜绝数字编号命名：

$getArticlesSql,$getPostsSql vs $sql1,$sql2

十天之后，看代码时遇到前者只要看变量名就能知道其大致内容，遇到后者要查看整个 $sql1 的赋值内容才能知道它的作用。如果出现 SQL 语句的交叉拼接，后者简直就是噩梦。

一些特殊规则：

对象变量名使用大写，对象里面的属性如果指向对象时也使用大写，首字母大写是对象或者类的专属。比如：

$Car = newCar();

$Car->Seat =new Seat();

常数一律完整大写。

4. 变量名的长度

变量名的长度适当就好，什么是适当？很大程度取决于代码的体积以及需要出现的变量数目。

变量名太短，不用说，除了自己现场记得其含义，过两天全世界都没人会记得它们的含义。类似于 $a, $b, $str, $arr 的写法，只有在写十几行以内的小代码才用得上，或者作为代码的小片段范围调用的，比如 foreach 里面。

也要避免过度的累赘，使用超长语句来当变量名，pear 里面随处可见。变量名太长就会分散过多精力来处理变量名的内容，和上面的弃用下划线命名法一样。必要时使用通用的缩写——不需要解释大家也能理解的缩写作为变量名的一部分，比如html。

个人的实践过程中很少出现 15 个字母以上的变量名。

5. 变量的数量

不要对一个变量多次变换数据类型。

对于数据类型的变换可以使用新的变量来存储其变化后的值，如果原变量不再使用，就 unset()，变量值出现大改动时，考虑使用新变量空间或者临时变量空间存储新的值。而开发过程中也会出现需要使用原变量值的情况，不用为了一时方便造成不要的麻烦——怎么把原来的数据弄出来？比如刚才提到的订餐名单的处理，保留原始的字符串就不用在后面 join 数组来恢复字符串的内容了。

代码里面对于多次改变值的内容和类型的option就是一场灾难。一个应用流程里面的变量名/属性名option 在函数/方法间传递了无数次，以各种形式出现，作为数组的 $option 下面有一个键名 'option' 的值，作为对象属性的 option 需要从传入的数组 $option 里获取值，同是 option 的属性其内容大不一样，很难在上下文里快速判断其可能内容。解决方法可以参照上面变量 $sql 的例子。

特例：

如果一个变量名能在应用流程的传递过程中保持数据类型一致、内容变化很小，应该使用同一个变量名称的。

三、匈牙利命名法

匈牙利命名法的出现有其历史背景，强类型语言、面向过程开发、功能简易的编辑器，对于没有变量标识(类似于 php 的 $)的强类型语言开发有一定的帮助，比如使用 o（对象）、a（数组）、s（字符串）标识变量。php 是弱类型语言，变量都有 $ 作为标识，而且变量类型是 string 或者是 integer 对运行结果没影响（至少大部分情况下是这样的），没有必要去强调这种区分。

匈牙利命名法会让阅读者过于关注变量名本身，而影响对变量内容整体的把握，不利于对代码整体的理解。另外，php 写完即可运行，对于程序的调试成本远不及强类型语言那么高，也不用如此刻意的去避免由于变量错误而带来的debug成本。

鼓励抛弃匈牙利命名法不是因为它的有用之处，而是它有不好用的地方，简单说就是：有用，但不那么好用。

引用维基百科中匈牙利命名法词条里面的一句话：

“大多数时候，看到一个变量就意味着知道了它的类型。但是，如果你不知道一个变量是干什么的，知道了它的类型也没什么帮助。”

想知道关于匈牙利命名法的更多？猛击这里

lamtin

确实很给力~必须顶!

sonic

个人习惯啦。
不过看了CI的手册发现作者是喜欢写普通变量全体小写加下划线；类名是大写字母开头加下划线。

BruceWolf

个人习惯啦。
不过看了CI的手册发现作者是喜欢写普通变量全体小写加下划线；类名是大写字母开头加下划线。 ...
sonic 发表于 2010-11-3 14:44

下划线在功能弱小的编辑器下面很有优势，比如当年写 C 的时候都是单色显示器。这种艰苦卓绝的环境也造就了一个时代的习惯。

面向对象时代使用驼峰和帕斯卡命名法的多了，又是一个时代的习惯。我没学习过 java，但是我觉得 java 的代码很漂亮。

php 官方手册里函数和变量的命名延续了 C 的习惯——下划线和缩写（php 官方手册某个地方提起过，说一些函数命名别扭是因为早期模仿 C 语言的风格，但是具体页面现在找不到了）；刚增加类支持的时候，类名都改成了帕斯卡命名法，函数和变量命的命名方法还是保持了下划线；SPL（Standard PHP Library）推出的时候方法名都改成了驼峰命名法，变量名没有做修改。

CI 也是传承了 php 官方早期的变量命名方法。CI 的类命名除了是习惯之外，还为了能够有效的 autoload。php v4 时代，这是个好习惯，而鼎力支持 v4 是 CI 推出时给自己打的特性标签之一。v5 里的 spl_autoload_register() 会让这种习惯不是那么必要，v5.3 的命名空间的推出，下划线就没有什么优势了。

不过，适合实际开发的习惯才是好习惯，php 官方也在逐步的改变习惯。
我那些个人习惯，就不适合完全带入到 CI 的开发里了。裸写的 php v5 的时候可以考虑一下。

Hex

个人习惯啦。
不过看了CI的手册发现作者是喜欢写普通变量全体小写加下划线；类名是大写字母开头加下划线。 ...
sonic 发表于 2010-11-3 14:44

    你仔细看 PHP 的函数命名，就是这个规则，我觉得，我们的命名规则应该和 PHP 自己的命名规则保持一致。

sonic

PHP不是JAVA当然写小写字母下划线咯。

BruceWolf

回复 6# sonic


看三楼，或者看手册，php 自身也在改变，你坚持的是什么时期的 php 呢

sonic

回复 7# BruceWolf

我随便啊。公司要怎样写规范我就怎样写咯。

BruceWolf

回复 8# sonic


好好混~那时候你能定规则了，而且能订好的规则~

小_宝

{:soso_e129:}，哦nice~~~  so good