首页 > 知识库 > 正文

升级 Java 编程规范的6个约定
2016-01-19 21:57:38   来源: mengyidan1988   评论:0 点击:

原文地址:https: dzone com articles upgrade-your-code-conventions-2 译文来自:OneAPM 作为Java开发人员,我们会遵循一系列的编码风格和开发习惯。习惯使然是一方面,另一方
原文地址:https://dzone.com/articles/upgrade-your-code-conventions-2
译文来自:OneAPM
作为Java开发人员,我们会遵循一系列的编码风格和开发习惯。习惯使然是一方面,另一方面,我们也从不停下脚步质疑这些习惯。一段时间以后,笔者养成了一些不同于常人的编码风格和开发习惯。当第一次了解到这些编码风格时,笔者感到又惊又气。但是,花了一段时间践行这些习惯之后,笔者意识到它们的确能造就更加简洁可控的代码库,同时也让开发者更加省心。

不要因这些想法的另类而否定它们,笔者建议你用几周时间尝试其中的一两条,如果你仍然不喜欢它们,换回以前的代码风格也用不了多久时间。

零注释(公共 API 除外)
笔者一度认为业内对于零注释这种编程习惯已经达成共识,但是当与许多同事合作之后,笔者发现事实并非如此。所以,让我们再次探讨这个问题:无注释。注释很快就会与代码脱节。假如你在一段代码的上面写了行注释,谁也不能保证下一个修改代码的人会更新注释。根据笔者的开发经验,没人会更新注释。原来的代码段可能被删除,业务需求也可能改变。因此,你的注释往往弊大于利。

对此,有个简单的解决方案,就是写自记录代码(self documenting code)。对变量、对象或者函数等进行命名时,选择能清晰表达其用途的名字。假如不够清晰,你需要对它们进行重构,将之拆分为更简洁的形式。只要能直观地表达其用途,过长的名字也无需担忧。别忘了编辑器有自动填写功能,没人需要敲出整个标识符的名字。

然而,公共API是一个明显的例外。假如你正在建立一个准备公开发版的库,那还是使用简洁的方法名比较好。不过, Javadoc对这种情况大有裨益,但也仅限此情况。

不要用 “Test” 为测试方法开头

确实没有必要这么做。你写的方法会注释为测试,方法所在的类也存在于测试包中。明眼人都知道那是测试。其实,测试方法名应该明确指出测试的内容与条件。例如, “reversesTheWordRandomToModnar()”或者“adds70ToBalanceOf100ToMakeBalanceOf170()”,这些名字都准确表达了测什么功能以及预期的结果。

如果你正在使用 IntelliJ ,有一款特别棒的插件叫做 Enso 。它可以将测试名转化成一个句子,一目了然地显示测试的内容。这意味着当你在注视任何类的时候, Enso 都会展示其说明文档。

不要使用@Override
这个观点争议颇多,请听笔者说完。假如你不使用 @override ,最坏的结果就是你重写了一个函数,而调用时执行的却是原版函数,而非重写的版本。值得庆幸的是,在测试驱动开发模式下,测试整段代码时就会定位到这个 bug 。这让 @Override 成了一段冗余的代码。显然,冗余的代码不仅没有好处,还会让人分心。因此,停止使用 @Override ,而依赖 TDD(测试驱动开发)。

不要使用 getX()/setY() 这样的函数名
这确实让人不由得感到恼火。 getXXX 和 setXXX 这种命名方式是 Javabeans 时代的前朝遗物。而 JavaBeans 时代早已过去,这种命名方式也不再适用了。后者让代码变得令人反感却没有带来什么好处。去掉 get/set 这类关键字有利于字段名称的简洁。例如, car.engine() 函数将生成一个引擎对象,而 car.engine(new v8()) 将引擎设置为新的型号。如果需要读取多层级内的对象(例如:car.lights().frontLeft() 对比 car.getLights().getFrontLeft()),前者依旧表达清晰而且代码更加简洁。这个编程习惯笔者一开始也很反对,后来逐渐改变了看法,现在非常热衷这一风格。

可运行的代码>高性能的代码

这段内容和代码风格关系不大,而是更加泛泛而谈。每次看到人们为了一个问题,精雕细刻地设计解决方案,花费大量的时间,笔者都会感到不悦。其实,在最基本的层面上解决问题然后测试性能。十有八九,这类方案都是高速,可扩展或符合其他时髦概念的。相反,笔者经常看到人们设计了一个复杂的缓存解决方案,结果没有提高性能却把代码弄成一团乱麻。解决问题时,先实施你能采取的最基本方案,然后再进行优化。最起码,这种方式能让你有实例证明问题已经解决。

使用自己的异常类型
笔者又一次错误地认为这一开发习惯是业内的共识。 Java 中的检查性异常 (Checked exceptions) 很糟糕,几乎所有其他编程语言(例如C#)都意识到了这一点,所以它们甚至没有这个类型。在笔者编写的任何应用程序中,都会创建自己的异常类型,在这些应用程序中抛出的任何异常都会用笔者创建的异常类接住,然后抛出运行时异常。这让代码更加整洁(笔者从未在程序中抛出大量 XXXException ),也意味着笔者能通过 log 追朔异常来自代码的哪一部分或者这是完全出乎意料的异常类型。

相关热词搜索:java 编程 language 编程语言

上一篇:不要和一种编程语言厮守终生:为工作正确选择
下一篇:Java日志记录的5条规则

分享到: 收藏