升级Java编码规范的几个约定（Java编码规范有哪些?）

升级Java编码规范的几个约定（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 追朔异常来自代码的哪一部分或者这是完全出乎意料的异常类型。