代码审查是一场没有硝烟的战争。当你的代码被同事逐行审视那些你习以为常的小习惯往往会成为最刺眼的伤口。对于Java新手来说逻辑错误反而容易发现真正致命的是那些透着“新手味”的坏习惯——它们让代码可以运行却让维护成为噩梦。坏习惯不是技术债是技术高利贷利滚利直到项目破产。我见过太多上线后半夜起来排查问题的现场十有八九都能追溯到一个“当时觉得很方便”的写法。下面这份清单写给所有觉得自己“代码能跑就行”的新手。它不涉及高深的算法也不涉及架构设计只关乎你每天写的每一行基础代码。能跑和能维护之间隔着一整条银河系。把这7个坏习惯改掉你的代码审查通过率会大幅提升。1. 用比较一切——字符串的“身份危机”新手最容易踩的坑就是用去比较字符串。在Java里比较的是两个引用是否指向同一个对象而不是值是否相等。String是一个对象不是基本类型。你以为在比内容实际在比身份证号。例如String a java; String b new String(java); if (a b) { // false永远不要这么写 }这个比较结果不是“相等”而是“不相等”。虽然字符串池会让一些常量字符串指向同一个对象但这完全依赖JVM的内部实现不是语言规范。用比较字符串等于把程序运行交给玄学。正确的写法是a.equals(b)。还没完如果a可能是null就用java.equals(a)避免NullPointerException。这个坏习惯为什么会存在因为很多新手从C语言或Python转过来习惯了比较原生值。在Java里只能用于基本类型int、char等和枚举。对于一切对象都必须用equals。别小看这个差别线上因为字符串比较错误导致的bug查起来极其痛苦因为日志里看起来一切正常。代码审查时看到出现在String上直接打回。2. 吞掉异常的“安静失败”第二个坏习惯是写出空catch块try { doSomething(); } catch (Exception e) { // 什么也不做 }或者更“进阶”一点打印一行注释就完事。吞异常是比不写异常更可怕的懒惰。你的代码表面上一切正常但实际上某个环节已经悄悄失败。最可怕的是失败被掩盖后系统继续运行直到数据错乱或者内存耗尽才爆发。到那时日志里干干净净连个线索都没有。正确做法要么捕获后记录日志至少log.error要么重新抛出包装过的异常要么用throw new RuntimeException(e)。如果你不知道要如何处理异常那就别捕获——让上层去处理。有些新手会说“我捕获异常是为了不崩溃。”但你的“不崩溃”是以牺牲可观测性为代价的。代码审查时看到空的catch块直接问“你打算让谁发现这个错误”没人回答就重写。当然偶尔有恰当的“吞异常”比如关闭资源时的IOException常被忽略但那属于特例。对新手而言先学会诚实地处理异常再谈何时可以无视它。审查清单上这一条是红线。3. 手动关闭资源——还记得finally吗在Java 7之前关闭资源要在finally块里写一堆模板代码。新手经常忘记关闭或者在finally里关闭时又触发异常。忘记关闭的流就像借了书不还图书馆迟早把你拉黑。例如FileInputStream in null; try { in new FileInputStream(file.txt); // ... } finally { if (in ! null) { in.close(); // 这里也可能抛异常 } }这段代码看起来严谨但如果在try块中in的初始化失败了finally里还是要判断是否非空。而且close()本身抛出的异常会覆盖原始异常。Java 7之后有了try-with-resources这才是正道try (FileInputStream in new FileInputStream(file.txt)) { // ... } catch (IOException e) { // ... }资源不是你的使用完就该归还在原来的状态。代码审查时看到手动在finally里关闭资源的先问一句“为什么不用try-with-resources”这个语法糖本质上是为了减少新手犯错的概率。偷懒要偷在正确的地方而不是偷在资源管理上。如果你还在用Java 6那当我没说但请至少把关闭逻辑封装成工具方法。4. 魔法数字的“占卜式编程”代码里出现裸的数字是新手最容易被逮住的坏习惯之一。比如if (status 3) { // 处理审核中状态 } else if (status 7) { // 已拒绝 }3是什么7是什么没人知道。魔法数字是代码里的邪教符号只有写它的人才能通灵其他人只能靠猜。几个月后你自己也会忘了3代表什么。更糟糕的是如果业务增加一个状态你需要小心翼翼地搜索所有status 3的地方改错一个就出事故。改进方案使用常量或枚举。给数字起一个名字就是给代码添一份尊严。例如private static final int STATUS_REVIEWING 3; private static final int STATUS_REJECTED 7;或者用枚举类型把行为也封装进去。不让魔法数字出现不是为了整洁而是为了让你明天的自己不被今天的自己坑。代码审查时看到数字直接问“这个数字的合理取值范围是什么业务含义是什么”答不上来等着重构。5. 裸的集合类型——泛型去哪儿了List list new ArrayList();这种写法在几十年前可以理解但如今在Java里就是主动放弃类型安全。丢掉了泛型等于把类型安全扔进了垃圾桶捡回来的时候已经带上了ClassCastException的细菌。例如List items new ArrayList(); items.add(hello); items.add(123); for (Object item : items) { // 强行转换运行时才发现类型不对 }编译器本来可以帮你阻止这类错误但因为你使用了裸类型编译器只能举手投降。使用裸类型相当于在代码审查时向同事宣告我不在乎类型系统。正确的做法是ListString items new ArrayList();泛型不仅让编译期发现错误还让代码更自文档化。看到ListString你就知道里面装的是字符串不用再去看添加元素的每一行。在新手代码中常见的还有Map不用泛型或者Class不用泛型。不论哪种都是坏习惯。代码审查时看到裸类型直接说“这是Java 5之前的代码吗”语气可以狠一点。6. 在循环里拼接字符串——性能杀手新手喜欢用拼接字符串这在单次拼接时没问题但如果放在循环里就是灾难。字符串是不可变的但你的耐心是可耗尽的。比如String result ; for (int i 0; i 10000; i) { result result i ,; }每一次执行都会在堆里创建一个新的StringBuilder对象然后转换成新的字符串。循环一万次就有两万个临时对象。这不仅是性能问题更是对GC的公开挑衅。正确写法StringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i).append(,); } String result sb.toString();如果你用的是Java 8更优雅的方式是StringJoiner或Collectors.joining。在循环外声明StringBuilder是和性能握手言和的最低成本方式。代码审查时看到循环里的字符串拼接最直接的反馈是“你能不能算出这段代码创建了多少个对象”新手往往算不出来那就让他们数一数。7. 返回null而不是空集合——NullPointerException的温床最后这个坏习惯坑人无数。写一个方法返回一个列表public ListUser findUsers(String name) { if (name null) { return null; } // ... }调用方拿到null后如果直接遍历或者调用.size()当场NullPointerException。返回null不是返回值是把地雷埋给调用你的同事等他一脚踩上。优雅的返回值是空集合public ListUser findUsers(String name) { if (name null) { return Collections.emptyList(); } // ... }或者用OptionalListUser但更推荐返回空集合。空集合是合法的状态null不是。别小看这一点很多空指针异常都源于这种“我以为不会有null”的侥幸。代码审查时看到方法可能返回null就问“为什么不返回空集合你的调用方必须记住判空这合理吗”如果调用的地方很多这无形中增加了大量防御代码。除了集合有些人还喜欢返回null当作“没有值”其实Java 8的Optional就是为了引导你避免裸null。用Optional表达值缺席比用null精确一万倍。把null限制在方法内部不让它跨过边界是Java程序员的职业素养。这7个坏习惯就像代码世界里的七宗罪。它们不会立刻让你崩溃但会在每一次代码审查中消耗同事的耐心。代码审查不是找茬而是让每个人都不必在深夜被叫起来处理自己曾经埋下的雷。改掉这些习惯你不仅会成为一个更好的Java程序员还会成为一个更受尊敬的人。好的代码不是一次写对的而是被一次次审查打磨出来的。下一次当你准备提交代码时先对照这份清单走一遍把改成equals把空catch补上日志把魔法数字换成常量把裸集合加上泛型……这些看上去微不足道的改动就是一名新手走向成熟的全部秘密。