程序命名

选择一个正确的名字是编程中最重要的事。以前酷壳向大家推荐过两篇文章《编程命名中的7+1个提示》 和《编程中的命名设计那点事》，今天再向大家推荐一篇。一个正确的命名可以让你更容易地理解代码的程序，好的命名可以消除二义性，消除误解，并且说明真实的意图，甚至可以让你有清新的气息以让你更能吸引异性。;-)

方法，类和变量

正确的名字可以让你的程序顾名思义，下面是一些提示：

• 不要使用”ProcessData()“这样的命名
  你如果在你的程序生涯中使用这样的函数名，那么这意味着你将是一个不合格的程序员而会被淘汰或解雇。请明确实际的功能。比如：ValidateUserLogin（验证用户登录） 或 EliminateDuplicateRequests（去除重复请求） 或 ComputeAverageAge（计算平均年龄），等等。
• 让命名来帮你设计程序
  让我们假装有这么一条规则是——“任何的函数是有输入/输出的”，那么，你需要思考的是所有的把input变成ouptut的步骤，然后，你可以选择一个简短的句了来说明你的这段程序，然后，把这个短句再精练一下，最终成为你的函数名，而那个短句则成了你程序的结构。

 

• 命令不应该是模糊的
  如果你有一个类名叫：FilterCriteria ，但实际上其可用于文件过滤，那么这个类应该叫做：FileFilterCriteria ，就算是你真要想要用 FilterCriteria，那它也应该是抽象类。
• 避免过多的工作
  这只是一个风格上的事情，但还是需要注意一下。在上面，我们使用到了 ValidateUserLogin 和EliminateDuplicateRequests两个名字，这两个命令看上去需要做很多比较复杂的事。所以，让你的名字变简单一些也有利于你的程序更容易阅读和维护。一个软件本来就是由不同的模块拼成，而一个模块又是由更细小的函数和类拼成。编程中，我们都知道，一个函数的尺寸应该控制在200行以内，一个类的接口应该控制在20个以内。所以，从其名字上我们就不要让一个名字取得太大了。
• 避免类名以 ”Manager” 结尾
  这样会让你类变成一个黑盒子，当然，有一些程序员喜欢使用这样的名字让那个类看起来好像更强大一些，但其实这样并不好。一般来说使用Manager这个字眼通常是使用工厂模式，或是一个容器，所以，对于一些最基本的算法或是数据结构的封装，最好是在其名字上体现这一算法或数据结构的名字，如：SortedList 和ConnectionPool 。
• 为你的枚举类型使用单数名字
  一个枚举类型会列出所有可能的值，所以，叫animalType 会比 animalTypes 要好。
• 匈牙利命名应该更多的关注名字的含义而不是类型
  匈牙利命名是一个以前很流行的命名方法，其给出了一整套的方法告诉你如何标记你的变量的类型，但可惜的是很多程序员过多的关注了变量了类型，而不是变量名的含义。而变量名的含义才是根本。
• 不要让名字隐藏了内在
  比如，我们有段代码需要处理用户的输入，把其转成UTF-8码，然后标准化（比如一些协议），最后再处理相应的转义字符。千万不要把这函数命名为Escape() ，因为你需要调用 ToUTF8() 以及NormalizeEntities() 最后才是 Escape() 函数。如果你希望使用一个函数名来做这三件事，那么，你宁可使用一个模糊的名字再加上充分的注释，而不是一个确切的名字。模糊的名字会让别人在阅读时想进去看看，而确切的名字则会让别人在阅读代码时忽略细节（这看起来和第一点有点矛盾，其实也是为了程序的易读）。比如：ProcessUserInput()
• 一致性, 一致性, 一致性
  强调文章和代码的一致性，就算是文档写得再详细，我们也要去读代码，所以文档主要是体现思路和反映需求和设计。在程序上，我们的命令应当和文档中的术语保持一致，而程序中的命名也应该是用和文档相同的风格，这样，我们可以少很多理解上的成本。
• 不要害怕改名
  有一些时候，你会觉得某具名字不合适，你需要改动一下。但你马上发现要改这个名字，需要修改很多的程序代码。在这里有一个原则，如果你的这个名字不是以API的方式发布时，那么你就应该不要害怕更改名字，就算是修改的工作量并不小，为了日后的更容易的阅读和维护，这是值得的。但是，如果这是一个API的名字，那我还是建议你不要改了，就算是你觉得这个名字烂得很。因为，当你的程序以API的形式发布后，会有N多的他人的程序依赖于这个名字，这个时候，兼容性和用户比什么都重要。

Frameworks 和 Libraries

你的用户是一个程序员，他需要使用你的代码进行二次开发。 Namespaces 将会是你重点需要注意的东西。

• 使用namespaces 而不是类的前缀
  希望你的编程序语言支持namespace，这样，你就可以使用它而不是在类名前面加前缀了。如果你所使用的语言不支持namespace，那么你应该上网看看其它程序员使用什么样的方式来区分自己的代码和别人的代码名字空间。
• 使用普通的namespace而不是使用公司名
  使用公司名做namespace并不是一个好的相法，因为公司名很容易变更，比如，公司因为被收购，被控告，合并，重组等原因需要更名。产品的名字同样也会改变。所以，使用一个普通的namespaces会好一些。如STL，ACE等。

数据库

Database Schemas 意为数据模型，所以，其名字应该和其领域是合乎逻辑的，而不是为了编程的方便。

• 数据表应使用复数
  别使用单数形式，这是因为在远古的ORM 中需要使用单数的形式来定义类名。而且，一个表中包含了许多行数据，所以也应该是复数的。如，”items“, “customers“, “journalEntries” 等等。,
• 为那些包括派生数据或是日常处理的表使用aux_ 和meta_ 前缀
  这些表中的数据都是用来做为临时处理的，所以，你需要一个前缀或是后缀来使他们区别于实际的表。
• 为主键加入表名
  如果你有一张表叫 ”driverLicenses” 而ID 列是主键，那么你应该把这个主键命名为”driverLicense_id” 而不是”id”。这样做的好处是，当你在连接两个表的时候，你不需要为主键指定表名，如： “driverLicense.id” 或”vehicle.id“，也不需要为其取别名。
• 使用后缀来标识类
  这样的例子很多，比如：ISBN 和Dewey Decimal numbers，VIN等等.
  Joe Celko有一篇文章叫 SQL Programming Style提到了下面这样的风格：
  _id 主键
  _nbr 字符串型的数位（有严格的规则，如：车牌号，身份证号，手机号等）
  _code 标准化编码(如：邮编，ISO 国家编码)
  _cat 种类名
  _class 子集
  _type 稍不正式的类名，比如，驾照中的，”摩托车”, “汽车”, and “出租车” 类型。

其它

• 对于“物理上”的东西，命名其是什么，而不是做什么
  比如某些物理上的名字，姓名，性别，文件路径，网络链接，文件描述符，下标索引，类的属性，这些都是物理上的东西，所以，其名字应该是标识其是什么，而不是用来做什么。
• 对于“逻辑上”的东西，命名其做什么，而不是是什么
  比如某些逻辑上的名字，函数名，数据结构，等。
• 避免”Category” 问题
  千万别使用”Category” 作为你的属性名，因为，你会马上发现，这并不靠谱，因为这就等于什么没有说。与此相类似的还有”type” ，”kind” ，”variant” ，”classification” ，”subcategory” 等，对于这些名字，没人知道其是什么东西。而应该使用更为明确的分类，如： “FuelEfficiencyGrade”, “PackagingType”, “AgeGroup”, “Flamability”, “AllergenLevel”, 等等。