不应当让读者在脑中把你的名称翻译为他们熟知的名称,这种问题经常出现在选择是使用问题领域术语还是解决方案领域的术语

单字母变量名就是个问题,在作用域较小,也没有名称冲突时,循环计数器自然有可能被命名为i或j(但千万别用字母)这是因为传统上惯用单字母名称做循环计数器,然而,在多数情况下,但字母名称不是个好选择;读者必须在闹钟将他映射为真实概念 ,仅仅是因为有了a和b,就要取名为c,实在并非像样的理由

程序员通常都是聪明人,聪明人有时会借脑筋急转弯炫耀其聪明,总而言之,假使你记得r代表不包含主机名和图式(scheme)的小写字母版URL的话,那你真是太聪明了

聪明程序员和专业程序员之间的区别在于,专业程序员了解,明确是王道,专业程序员善用其能,编写其他人能理解的代码

类名

类名和对象名应该是名词或名词短语,如customer,wikipage,account和addressParser.避免使用manager,processor,data或info这样的类名,类名不应当是动词

方法名

方法名应当是动词或动词短语,如postPayment,deletePage或save,属性访问器,修改器和断言应该根据其值命名,并依javabean标准加上get,set和is前缀

string name=employee.getName();
customer.setName("mike");

if(paycheck.isPosted())

重载构造器时,使用描述了参数的静态工厂方法名,例如

Complex fulcrumPoint = Complex.FromRealNumber(230);

通常好于

Complex fulcrumPoint = new Complex(23.0)

别扮可爱

如果名称太耍宝,那就只有同一作者一般有幽默感的人才能记住,而且还是在他们记得那个笑话的时候才行,谁会知道名为HolyHandGrenade的函数是用来做什么的呢?没错,这名字挺伶俐,不过DeleteItems或许是更好的名称,宁可明确,毋为好玩.

扮可爱的做法在代码中经常体现为使用俗话或俚语,例如,别用whack()来表示kill(),别用eatMyShorts()这类与文化紧密相关的笑话来表示abort(),言到意到,意到言到

每个概念对应一个词

给每个抽象概念选一个词,并且一以贯之,例如,使用fetch,retrieve和get来给多个类中的同种方法命名,你怎么记得住哪个类中是哪个方法呢?很悲哀,你总得记住编写库或类的公司,机构或个人,才能想的起来用的是哪个术语,否则,就得耗费大把时间浏览各个文件头及前面的代码

eclipse和intelliJ之类的现代编程环境提供了与环境相关的线索,比如某个对象能调用的方法列表,不过要注意,列表中通常不会给出你为函数名和参数列表编写的注释,如果参数名称来自函数声明,你就太幸运了,函数名称应当独一无二,而且要保持一致,这样你才能不借助多余的浏览就能找到正确的方法

同样,在同一堆代码中有controller,又有manager,还有driver,就会令人困惑.DeviceManager和Protocol-Controller之间有何根本区别?为什么不全用controllers或managers?他们都是drivers吗?这种名称,让人觉得这两个对象是不同类型的,也分属不同的类

对于那些会用到你的代码的程序员,一以贯之的命名方法简直就是天降福音

别用双关语

避免将同一个单词用于不同目的,同一术语用于不同概念,基本上就是双关语了,如果遵循”一词一义”规则,可能在好多个类里面都会有add方法,只要这些add方法的参数列表和返回值在语义上等价,就一切顺利

但是,可能会有人决定为”保持一致”而使用add这个词来命名,即便并非真的想表示这种意思,比如,在多个类中都有add方法,该方法通过增加或连接两个现存值来获得新值.假设要写个新类,该类中有一个方法,把单个参数放到群集(collection)中,该把这个方法叫做add吗?这样做貌似和其他add方法保持了一致,但实际上语义却不同,应该用insert或append子类词来命名才对,把该方法命名为add,就是双关语了

代码作者应尽力写出易于理解的代码,我们想把代码写的让别人能一目了然,而不必殚精竭虑的研究,我们想要那种大众化的作者尽责写清楚的平装书,我们不想要那种学者掘地三尺才能摆明其中意义的学院派模式