C# 标准命名规范

　笔者从事开发多年，有这样一种感受，查看一些开源项目，如Spring、Apache Common等源码是一件赏心悦目的事情，究其缘由，无外两点：1）代码质量很是高；2）命名特别规范（这可能跟老外的英语水平有关）。

　　要写高质量的代码，不是一件容易的事，须要终年累月的锻炼，是一个量变到质变的过程，但要写好命名，只须要有比较好的英语语法基础和一种自我意识便可轻松达到。本博文将会结合本人的开发经验，总结出若干命名规则，这些命名规则纯属我的的使用习惯，不表明是一种理想的规则，在这里列举出来，供你们交流讨论。

　　1. 切忌使用没有任何意义的英语字母进行命名

for(int i=0; i<10; i++) {     //... }

　　这是在不少教Java基本语法的书上常见的代码片段，做为教学材料，这样写无可厚非，但做为真正的代码编写，程序员必需要养成良好的习惯，不要使用这种没有任何含义的命名方式，这里可使用“index”。

　　2. 切忌使用拼音，甚至是拼音首字母组合

cishu =5;  // 循环的次数 zzje = 1000.00;  // 转帐金额

　　笔者在作代码检查的时候，无数次遇到过这样的命名，令人啼笑皆非。

　　3. 要使用英文，并且要使用准确的英语，不管是拼写仍是语法

• 名词单数，必须使用单数英文，如Account、Customer。
• 对于数组，列表等对象集合的命名，必须使用复数，并且最好按照英文的语法基础知识使用准确的复数形式，如 List<Account> accounts、Set<Strategy> strategies。
• 对于boolean值的属性，不少开发人员习惯使用isXXX，如isClose（是否关闭），但这里有两点建议：1）最好不要带“is”，由于JavaBean的规范，为属性生成get/set方法的时候，会用“get/set/is”，上面的例子，生成get/set方法就会变成“getIsClose/isIsClose/getIsClose”，很是别扭；2）因为boolean值一般反映“是否”，因此准确的用法，应该是是用“形容词”，上面的例子，最终应该被改成 closed，那么get/set方法就是“getClosed/isColsed/setClosed”，很是符合英语阅读习惯。

　　4. 方法名的命名，须要使用“动宾结构短语”或“是动词+表语结构短语”

　　笔者曾看到过千奇百怪的方法命名，有些使用名词，有些甚至是“名词+动词”，并且，若是宾语是一个对象集合，仍是最好使用复数。

createOrder(Order order) //good     orderCreate(Order order) //bad removeOrders(List<Order> orders) //good  removeOrder(List<Order> order) //bad

　　5. 对于常见的“增删改查”方法，命名最好要谨慎

• 增长：最多见使用create和add，但最好根据英语的语义进行区分，这有助于理解，create表明建立，add表明增长。好比，要建立一个Student，用createStudent要比用addStudent好，为何？想一想若是有个类叫Clazz(班级，避开Java关键字），如今要把一个Student加入到一个Clazz，Clazz很容易就定义了一个 addStudent（Student student)的方法，那么就比较容易混淆。
• 修改：常见的有alter、update、modify，我的以为modify最准确。
• 查询：对于获取单个对象，能够用get或load，但我的建议用get，解释请见第7点的说明；对于不分条件列举，用list；对于有条件查询，用search（最好不要用find，find在英文了强调结果，是“找到”的意思，你提供一个“查询”方法，不保证输入的条件总能“找到”结果）。
• 删除：常见的有delete和remove，但删除建议用delete，由于remove有“移除”的意思，参考Clazz的例子就能够理解，从班级移除一个学生，会用removeStudent。

　　6. 宁愿方法名冗长，也不要使用让人费解的简写

　　笔者曾经遇到一个方法，判断“支付帐户是否与收款帐户相同”，结果我看到一个这样的命名：

checkIsOrderingAccCollAccSame(...)

　　很难理解，我立刻把它改成：

isOrderingAccountSameAsCollectionAccount(...)

　　虽然有点长，但很是容易阅读，并且这种状况老是出现得比较少。

　　7. 若是你在设计业务系统，最好不要使用技术化的术语去命名

　　笔者曾经工做的公司曾经制订这样的命名规则，接口必需要以“I”开头，数据传输对象必须以“DTO”做为后缀，数据访问对象必须以“DAO”做为后缀，领域对象必须以“DO”做为后缀。我之因此不建议这种作法，是但愿设计人员从一开始就引导开发人员，要从“业务”出发考虑问题，而不要从“技术”出发。因此，接口不须要非得以“I”开头，只要其实现类以“Impl”结尾便可（注：笔者认为接口是与细节无关的，与技术无关，但实现类是实现相关的，用技术化术语无可口非）；而数据传输对象，其实无非就是保存一个对象的信息，所以能够用“**Info”，如CustomerInfo；领域对象自己就是业务的核心，因此仍是以其真实名称出现，好比Account、Customer；至于“DAO”，这一个词来源于J2ee的设计模式，笔者在以前的项目使用“***Repository”命名，意味“***的仓库”，如AccountRepository，关于“Repository”这个词的命名，是来源于Eric Evans的《Domain-Driven Design》一书的仓库概念，Eric Evans对Repository的概念定义是：领域对象的概念性集合，我的认为这个命名很是的贴切，它让程序员彻底从技术的思惟中摆脱出来，站在业务的角度思考问题。说到这里，可能有人会反驳：像Spring、Hibernate这些优秀的框架，不是都在用“I”做为接口开头，用“DAO”来命名数据访问对象吗？没错！但千万别忽略了语义的上下文，Spring、Hibernate框架都是纯技术框架，我这里所说的场景是设计业务系统。

　　8. 成员变量不要重复类的名称

　　例如，不少人喜欢在Account对象的成员变量中使用accountId，accountNumber等命名，其实没有必要，想一想成员变量不会鼓孤立的存在，你引用accountId，必须是account.accountId，用account.id已经足够清晰了。

　　“勿以善小而不为，勿以恶小而为之”、“细节决定成败”，有太多的名言告诉咱们，要注重细节。一个优秀的程序员，必需要有坚实的基础，而对于命名规则这样容易掌握的基础，咱们何不现行？