很多人错误地认为编码只是熟练手的事情，其实要成为优秀的编码人员就必须进行自我剖析，抛弃不良的习惯，展示自己优秀的编码能力。通常不良的编码习惯有很多种，这里列出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，这样是不行的！—相信天外有天吧，更多更好的工具等待着你去发掘。
摘自:《改善JAVA程序的151个建议》
