编程中离不开命名。命名是指给变量、方法或函数、类、文件起名字。命名的最基本要求是，要遵守特定编程语言对命名的要求。比如，在PHP中，变量名，以 $ 符号开头，第二个字符，必须是下划线(_)、字母，其他部分，可以是英文字母、数字。命名不要使用编程语言中的关键字和保留关键字。
程序员的大部分工作是维护工作，大部分时间是在读代码。代码可读性好，有助于提升程序员的工作效率。好的名字，能增强代码可读性。
好的命名，需要遵循下面一些原则。
名字要“名副其实”。代码作者或其他开发者看到名字的时候，要能够“忘文生义”。比较下面的代码：
int d; //消逝的天数
int elapsedDay;
第一行代码，不看注释，看不出d表示什么意思。第二行代码，没有代码，读者也能知道什么意思。如果能够用代码传达作者意图，就不必写注释。
名字的区别要有意义。如果两个名字不同，那么它们传达的意思也应该不同，否则，就是多余。getUser和getUserInfo，这两个名字虽然不同，但都是表示获取用户信息，为什么不选择更简洁的那个呢？getUser和getUserId，名字不同，传达的意思也不同，这种区别，非常有必要。
名字应该避免误导性。用户列表，命名为userList，就会让大部分程序员误以为userList是一个list类型的变量（PHP程序员可能不会受此误导，但大部分专业的程序员都会被误导）。
名字中要避免废话。永远不要在变量中加variable，比如，nameVariable，userVariable。不要在表名中加上table。不要在name之类的字符串变量中加上string，没有人会认为name是一个非字符串类型的变量。
名字要可搜索。不要使用单字母、数字命名。在thinkPHP源码中，有很多单字母方法，比如U，我曾经模仿这种命名风格。其他人维护我的代码之时，抱怨搜索U时得到许多结果，我理直气壮地说thinkPHP也是这么做的。
为了使名字可搜索，宁可把名字起得长一些。名字的长度，和该名字的作用域成正比。
名字要可以读出来。在交流中，有时需要说变量名或函数名，如果名字不可读，与他人交流的时候，将会发生很可笑的事。如果一个名字不可读，那么交流的时候，可能只能拼写出那个名字，或者说，那个什么。
成员变量不需要加前缀。类的属性即成员变量，加上m_前缀，毫无必要。
命名要带上语境。表示邮件地址的一组变量，firstName，lastName，street，state，读者不能从它们看出这组变量是关于地址的。改成firstNameAddress，lastNameAddress，streetAddress，stateAddress，就能清晰地传达出，它们是一组关于地址的变量。另外一种更好的方式是创建一个地址类Address，然后声明
firstName，lastName，street，state这些类属性。
使用解决方案领域的名称来命名。代码中的名称，读者往往是程序员，使用程序员能够理解的词语能准确地传达意思。比如 ，centerVistor，程序员都知道vistor是指访问者模式。
使用问题领域的名称来命名。找不到合适的解决方案领域名称的时候，可以选用问题领域的名称。程序员即使不明白某个问题领域的名称，也可以询问该问题领域的人员。
命名规则要始终保持一致。如果在一些地方使用controller表示控制管理，就一直使用controller表示“控制管理”这个概念，而不能在有的地方使用controller，在其他地方使用manger，甚至在另外的地方又使用processer。在编程中，我命名的时候，就违背了这一原则。比如，插入数据的方法，有时命名为addData，有时又命名为insertData。同一个概念，保持一致的命名规则，读者读到名称的时候，就能迅速知道这类方法的作用。
命名要避免扮可爱，避免使用只有很少人能看懂的词汇（这种命名方式又叫“语法糖”），要使用通用词汇。
类方法或函数命名，使用动词或动词短语。类名、类属性或变量命名，使用名词或名词短语。
不要使用区别极小的名字命名。getTimeStampNWhenIsThursday，getTimeStampYWhenIsThursday，这两个不同的名称，要看几秒，才能看出它们的区别？
在编程实践中，我并未明确地遵守一种编码规范，所在团队也没有严格的编码规范。我并未从严格遵守编码规范的代码中获得阅读上的便利，比如，读到add，就知道是插入数据；读到delete，就知道是删除数据；等等，也就是说，编码规范，并未让我不读注释、不去看代码，就能知道那些代码在做什么。但是，所在团队，网络资料，的确提倡：编程，要遵守编码规范。试着去理解一下编码规范的必要性。以最基本的花括号（{}）是应该和代码在同一行还是换行为例。人依靠惯性做事，往往会快速、顺畅很多。一个看惯了A风格花括号的人，读B风格花括号的代码，看起来多少会有些障碍。
我必须尽快整理一份编码规范（尽量兼容团队规范），然后在编程实践中严格对照着编码规范，去实践规范。
