你的位置:首页 > ASP.net教程

[ASP.net教程]编写高质量的代码——从命名入手


作者: Johnny.Liang  发布时间: 2015-05-28 17:48  阅读: 3444 次  推荐: 30

笔者从事开发多年,有这样一种感觉,查看一些开源项目,如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) //badremoveOrders(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已经足够清晰了。

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