首页 » 编写高质量代码:改善Java程序的151个建议 » 编写高质量代码:改善Java程序的151个建议全文在线阅读

《编写高质量代码:改善Java程序的151个建议》建议150:抛弃7条不良的编码习惯

关灯直达底部

很多人错误地认为编码只是熟练手的事情,其实要成为优秀的编码人员就必须进行自我剖析,抛弃不良的习惯,展示自己优秀的编码能力。通常不良的编码习惯有很多种,这里列出7条编码者经常会犯的错误,提醒大家注意。

(1)自由格式的代码

如果我们不从一个团队角度出发,而是从程序员个体角度去看问题:A项目的风格和B项目的风格迥异,甚至是在同一个项目的不同类中风格也不同,不用缩进,不添加注释,想加接口就加个接口,不想加就不加,我们要的是“自由,自由,还是自由”。——这不是一个成熟的职业者应该具有的,我们应该保持自己的代码风格,即使它是错的,也比没有风格要好。

(2)不使用抽象的代码

这也算是IDE的便利性造成的习惯,一个业务类不进行抽象,直接进行编码,在需要修改时,要么依靠IDE批量重构,要么通过查找替换的方式重构,很方便,不是吗?而且,随着SSH的普及,“无抽象”编程进一步横行起来。要接口何用?想要修改的时候直接修改XML配置文件就可以了,要什么接口!系统间数据交互?序列化为XML传递,与接口何干?!

这是一种非常拙劣的习惯,抽象的意义不在于编码,而是在于对业务的理解,接口是对业务宏观的描述,而不是实现代码。

(3)彰显个性的代码

技术人员追逐最新的技术,这本是无可厚非的,但是新技术只能作为技术的一个方向,不适合立刻投入生产中,要知道一个项目的运行质量是远远高于代码质量的,不要为了一个新颖的API就在生产中尝试使用,不要做小白鼠。

这里介绍一个“最小惊诧原则”(Principle Of Least Surprise简称POLS,或者Principle Of Least Astonishment简称POLA),其意是说要使用最常见的,而不是最新颖的功能。在编码时,应寻找最常用的方法来实现,比如,同样有两个方法都能实现一个算法,选择那个最常用的,而不是那个别人一看就惊呼“哇哦,算法这么牛”的,让普通人都能看懂的代码才是最简洁的代码。

最小惊诧原则也同样适用于UI设计,当操作界面上两个元素冲突或重叠时,首选是那个不让用户感到吃惊的元素。

(4)死代码

可能是忘记删除的代码,也可能是故意保留的类似“到此一游”的签名代码,这些代码按照正常的执行逻辑是不可能被执行到,但是在某些未知情况下它就是执行了,此时就会产生严重的影响。

(5)冗余代码

写了一个实现类,过了N天后又废弃了,之后这个类就永久地保留下去了,没人知道它为什么没被删除掉。甚至有时候竟然还能在生产机上寻找到测试程序的身影,它的生命力可谓顽强呀!估计如果有一天将生产机移植到月球上,这段代码可能还能存在。

曾经遇到过一个项目,项目中建立了单元测试机制,但在生产代码中还能看到main方法,谓之“测试方便”——删除它,它不应该在这里!

(6)拒绝变化的代码

哲学上说任何事物都是在运动着的,但是我们有些代码却不遵循这一个规律,一个在JDK 1.1中就过时的方法还还能在使用JDK 1.6项目中存在,谓之曰“没有坏,就不要去修它”——该重构它了,它没坏,但它赖以生存的环境已经变了!

我甚至还遇到过一个新项目还准备使用一个5年前的工具包(此工具包已经经历了3次大的版本变更),谓之曰“好用,没有什么Bug”,但不要忘记了,环境在前进,我们不跟随就只能落单——不会有人陪着我们找Bug,不会有人去修正,不会有人去做性能优化,我们能做的就是孤军奋战了!

(7)自以为是的代码

这是我们编码的最大忌讳,认为自己无所不能,编码不会出现任何错误,于是不编写测试代码,或者测试代码只是为了应付质量检查人员,那等待我们的恶果就是系统上线后彻夜彻夜地修复Bug——自己排除自己埋下的地雷。

自以为是还表现在对产品或工具的选型上,相信自己编写的工具类,而不是开源工具,宁愿自己写序列化工具,也不选择kryo或protostuff;宁愿自己写日期处理工具,也不选择Joda或date4j;宁愿自己写批处理框架,也不选择Spring Batch,这样是不行的!——相信天外有天吧,更多更好的工具等待着你去发掘。