升级 Java 编程规范的6个约定

2顶
5踩

2016-01-11 16:40 by 副主编 mengyidan1988 评论(9) 有5900人浏览

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 追朔异常来自代码的哪一部分或者这是完全出乎意料的异常类型。

来自: OneAPM

分享到：

2
顶

5
踩

评论共 9 条请登录后发表评论

9 楼 =寂寞_狐狸= 2016-01-26 15:03

默默潜水好多年，这是潜水3年来第一次发表言论，说实话，真的看不下去了！
首先楼主你是猴子派来的吗？
其次，我深表怀疑楼主你是来骗回复，骗经验的！
最后，楼主你可以转行了，不要在我们java界了，扛不住你啊~~~

8 楼 huscarter 2016-01-24 20:30

不知道编者做过项目管理没有，你这几条规范如果真的让团队人员执行，对项目开发和维护都将产生不好的影响。
1、零注释。
1-1、同意你属性命名的可读性，但是必要的注释不能少，毕竟你的名称不是详细说明。
1-2、类的注释不能少（包括类的作用、创建则、和时间等），也许你自己看一个类就知道它是为什么而创建的，但是当你离职了，项目交给了别人，当接受的人看到你这个类时就会想CTM。
1-3、一些方法需要添加方法参数和方法的逻辑说明，（当然不是要求所有的方法都得加注释），有些逻辑比较复杂的方法必须加上。不信的话，你过个1个月再去看自己的代码，你就会很庆幸这茫茫代码中的这一片绿洲了。
2、不要使用 getX()/setY() 这样的函数名。
2-1、我就纳闷了，编者你解析过json字符串吗？
2-2、个人认为javabean规范并不过时（只是很多人不知道其意义何在）。将对象的属性通过get和set方法对外公开有时很有必要。比如项目中要求商品的价格都保留小数点后2位，那么我们可以只在getPrice()里将价格处理成小数点后2位，然后返回就行了，不需要在项目里的每个地方对它做处理。
3、可运行的代码>高性能的代码。
3-1编者提到“解决问题时，先实施你能采取的最基本方案，然后再进行优化”。这种只能是因人而异，不能定为规范。很多有经验的开发人员在动键盘之前进行构思，作出设计，不一定就会把代码搞乱了。
4、使用自己的异常类型
4-1、编者提到不要使用java的异常检测，做项目都会创建自己的异常类，如果有异常，自定义异常类会接住，然后抛出运行时异常。我要问的是项目要记录log日志，你的自定义异常类有划分log的等级吗？

少年，请开下门，我是查水表的...

7 楼 r361251 2016-01-21 17:18

"零注释（公共 API 除外）" 和 "不要使用 getX()/setY() 这样的函数名" 都已经成为大家约定俗成的规范了,还让大家不要这样做?楼主是来逗逼的?

6 楼 kioxo 2016-01-20 16:40

几个点都很有争议，零注释中说很少人改注释，其实这已经是个问题，不能在一个问题已知而不处理却使用另一种途径去规避。第二就是代码本来就需要简洁比如一个算法很复杂的方法，那你名称岂不是要盖住几行了？而且没有注释的话，也许你隔了几个月自己都要仔细读代码才能理解了。

5 楼 JianbinJava 2016-01-20 12:48

不写注释,简直无法容忍.谁TMD整天把你的代码完全读一遍然后再思考你真正的意图..
这六条一条都不能放过.楼主可以转行不用写Java了.

4 楼 sgq0085 2016-01-18 16:23

这是多初级的程序员拍脑袋想出来的？

3 楼 mfkvfn 2016-01-15 14:43

关于“不要使用 getX()/setY() 这样的函数名 ”这一条，的确不怎么好，还是jQuery这种无参数代表get有参数代表get更好，且set支持连缀式写法。

But，现在各大主流框架，如Spring,Hibernate，Struts、JSON系列化等都通过反射来找getter/setter方法，如果不这么写，就玩不转了。

所以理想很丰满，现实很骨感。

2 楼 mangguo 2016-01-12 09:40

这里有java的免费互动学习内容，可以试试这样行不行。

1 楼飞天奔月 2016-01-12 00:32

要是这么来小编你出来我保证不打死你

发表评论

您还没有登录,请您登录后再发表评论

2顶5踩