PHP变量命名建议

发表时间: 2008-7-05 23:16 作者: DJ. 来源: PHPChina 开源社区门户

PHP是一种弱类型语言，如果程序里有许多变量，加上PHP许多函数命名都十分混乱，乱上加乱，看得也就眼花缭乱了。

统一编码风格，甚至变量命名，在团队开发中非常重要。

本人从事多年PHP开发，为使所带领的团队更加效，渐渐形成了一种PHP的命名习惯（后面有朋友说是早已存在的匈牙利命名法），使自己的程序看起来十分明了。

下面我就把经验给大家，不一定适用于别人，但还是分享一下。

string,字符串型,在变量前面加str

array,数组型, 在变量前面加a, 一维数组使用名词单数，多维数组使用词复数

integer,整数型变量，在前面加上'n'

boolean,布尔型在前面加上'b'

float,浮点型, 在前面加上'f'

指针类型,比如类。在前面加上'p'

resource,资源型，在前面加上'rs'

未明变量，使用mx

自定义函数，使用fn_开头

一个综合的例子(使用分页类):

[ 本帖最后由 DJ. 于 2008-7-7 17:11 编辑 ]

我也来说两句 查看全部评论相关评论

fhjr999 (2008-7-05 23:23:03)

这里好像弄错了，应该是$fSave

支持，一套好的命名规范，确实可以让代码清晰易读的多。
yarco4 (2008-7-05 23:33:39)

单纯匈牙利命名法, 过时
我现在组合使用命名法. 感觉不错

[ 本帖最后由 yarco4 于 2008-7-5 23:34 编辑 ]
DJ. (2008-7-05 23:38:15)

QUOTE:
原帖由 yarco4 于 2008-7-5 23:33 发表
单纯匈牙利命名法, 过时
我现在组合使用命名法. 感觉不错
我还不知道有匈牙利命名法这个法则，你一说，我搜了一下，确实挺像。
不过我这不是什么匈牙利命名法，自己形成的习惯。
fhjr999 (2008-7-06 01:31:15)

很正常的命名规范，很多人采用，我见过几个例子也是这样命名的。
飘渺晴霜 (2008-7-06 02:22:24)

LZ的命名挺规范的，
thaiki (2008-7-06 02:51:53)

呃 ....果然很规范....
DJ. (2008-7-06 10:16:56)

QUOTE:
原帖由 fhjr999 于 2008-7-6 01:31 发表
很正常的命名规范，很多人采用，我见过几个例子也是这样命名的。
呵呵，那更好，我还以为只有我们有这样的习惯呢。
很少有机会看别人的代码。
要是大家都有这样的习惯就好了
fyland (2008-7-06 15:27:54)

帕斯卡命名、骆驼命名法、匈牙利命名法
DJ. (2008-7-06 16:01:11)

要是我早个二三十年出生就好了，这就应该叫DJ命名法，呵呵。
ShiningRay (2008-7-06 16:59:27)

QUOTE:
原帖由 DJ. 于 2008-7-6 16:01 发表
要是我早个二三十年出生就好了，这就应该叫DJ命名法，呵呵。
不过早二三十年，老兄可不能出生在中国哦

其实有些东西大可不必使用匈牙利法则来约定，因为一些约定好了的变量名本身已经告诉你这是什么类型的
比如，一般来说，大家看到$conn大家都知道这是一个resource类型
而如果$conn是哪个类比如Connection的实例，那么仅仅使用$objConn或$oConn的命名方式，你也不能判断他实际的类型和行为
再比如，看到$count就应该知道他是一个整数，如果有人用$iStr却放一个整型进行整数操作，显然他不想让别人读懂他的代码

无论这些变量怎么命名，如果要被外部调用，或者代码要被人修改，都应该在文档中说明，否则，仅仅是一些命名规则，一样让人摸不着头脑。

现在编程（尤其是OOP）中，开发工具越来越强大，匈牙利法则一般不怎么用了。除非特别重要的会以一些特殊的形式进行标注，比如以I开头，表示接口等，其他的都应该通过文档给出，而且变量起名时，使用言简意赅一目了然的单词。
ShiningRay (2008-7-06 17:00:10)

抨击匈牙利命名法［转］

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

本文要证明的是：匈牙利命名法是一个坏的命名规范。本文的作用范围为静态强类型编程语言。本文的分析范本为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++语言：

1.class：如果说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 噩梦加上修饰是什么？还是噩梦。

你愿意做镣铐上的舞者吗？
DJ. (2008-7-06 17:46:01)

QUOTE:
原帖由 ShiningRay 于 2008-7-6 16:59 发表

不过早二三十年，老兄可不能出生在中国哦

其实有些东西大可不必使用匈牙利法则来约定，因为一些约定好了的变量名本身已经告诉你这是什么类型的
比如，一般来说，大家看到$conn大家都知道这是一个resource类型 ...
呵，开个玩笑而已。早生二三十年，恐怕这辈子不会碰电脑。
匈牙利命名法我还是发了这贴子后有人说了才知道，我这种人属于闭门造车类型的，你说出个专有名词来，我恐怕听都没听过。至于它的利与弊，我这里就不想讨论了
并且我发这贴也只是建议，相信有经验的程序员都有自己的一套

[ 本帖最后由 DJ. 于 2008-7-6 17:47 编辑 ]
七月十五 (2008-7-06 18:02:17)

一般骆驼法比较人性
DJ. (2008-7-06 18:10:06)

仔细分辨起来，我这什么都像，却什么法都不是。
我不喜欢摆弄这些名词。
lgy1 (2008-7-06 18:40:56)

的确不错，但会牺牲一些键盘输入的时间。
DJ. (2008-7-06 19:14:56)

QUOTE:
原帖由 lgy1 于 2008-7-6 18:40 发表
的确不错，但会牺牲一些键盘输入的时间。
相比其他程序写起来需要 int varname 这样，其实也差不多
slawdan (2008-7-06 20:42:16)

……
以前用过 n f a s这些前缀
自从用php以来，完全抛弃了

有phpdoc足够了，为什么要用这些个前缀？
DJ. (2008-7-07 09:17:13)

觉得看着明了呀

现在觉得整数型的还是用n方便一点。

一会改过来
slawdan (2008-7-07 10:25:11)

QUOTE:
原帖由 DJ. 于 2008-7-7 09:17 发表
觉得看着明了呀

现在觉得整数型的还是用n方便一点。

一会改过来
浮点的你可以只用f呢~
等你写一段时间就知道写不写没太大用处了~
DJ. (2008-7-07 10:35:15)

QUOTE:
原帖由 slawdan 于 2008-7-7 10:25 发表

浮点的你可以只用f呢~
等你写一段时间就知道写不写没太大用处了~
写了几年，可不止一段时间了
不写还不习惯，有没用处只有用过才知道　
我现在看回几年前的代码，依然是一目了然的感觉

查看全部评论

我也来说两句

月度关注热点

最新更新主题

PHP变量命名建议

我也来说两句 查看全部评论 相关评论

fhjr999 (2008-7-05 23:23:03)

yarco4 (2008-7-05 23:33:39)

DJ. (2008-7-05 23:38:15)

fhjr999 (2008-7-06 01:31:15)

飘渺晴霜 (2008-7-06 02:22:24)

thaiki (2008-7-06 02:51:53)

DJ. (2008-7-06 10:16:56)

fyland (2008-7-06 15:27:54)

DJ. (2008-7-06 16:01:11)

ShiningRay (2008-7-06 16:59:27)

ShiningRay (2008-7-06 17:00:10)

DJ. (2008-7-06 17:46:01)

七月十五 (2008-7-06 18:02:17)

DJ. (2008-7-06 18:10:06)

lgy1 (2008-7-06 18:40:56)

DJ. (2008-7-06 19:14:56)

slawdan (2008-7-06 20:42:16)

DJ. (2008-7-07 09:17:13)

slawdan (2008-7-07 10:25:11)

DJ. (2008-7-07 10:35:15)

我也来说两句查看全部评论相关评论