作为即将成为Java开发人员你，大多数都会遵循一系列的编码风格和开发习惯习惯，使然是一方面，

另一方面，

我们也从不停下脚步质疑这些习惯，一段时间以后，笔者养成了一些不同于常人

的编码风格和开发习惯

当第一次了解到这些编码风格时，笔者感到又惊又气

但是，花了一段时间践行这些习惯之后

笔者意识到它们的确能造就

更加简洁可控的代码库

同时也让开发者更加省心

不要因这些想法的另类而否定它们

笔者建议你用几周时间尝试其中的一两条

如果你仍然不喜欢它们

换回以前的代码风格也用不了多久时间

不要用 “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 追朔

异常来自代码的哪一部分或者

这是完全出乎意料的异常类型