代码质量好坏，最重要的标准就是别人读起来费不费劲。代码首先是写给人看的，然后才是给机器运行的。一段好代码，应该让阅读的人很快就能明白它在做什么，而且改起来也不容易出错。

烂代码长什么样？

• 乱七八糟：结构混乱，命名随意，找不到头绪

• 逻辑绕弯：一层套一层的if-else，看得头晕

• 简单问题复杂化：明明很简单的事情，非要写得很复杂

• 像密码一样难懂：只有写代码的人自己能看懂，过段时间可能连他自己也忘了

• 不敢修改：改一个地方，不知道会影响到哪里

好代码是什么感觉？

• 清晰明了：看一眼就知道要做什么

• 简单直接：没有多余的代码

• 名副其实：名字就能说明白用途

• 容易扩展：各个部分相对独立，改这里不会影响那里

第一，起个好名字

名字是代码的第一印象，起得好能省很多解释的功夫。

不要这样起名字：

• 随意缩写：比如usrMgr（是UserManager吗？）、procData（到底是处理过的数据还是在处理数据？）

• 意义模糊：data、info、temp、doWork()这种名字等于没说

• 长得太像：XYZController和XYZManager有什么区别？小写字母l和数字1根本分不清

• 用生僻词：除非必要，不要用只有特定领域才懂的术语

• 需要注释才能懂：如果名字本身说不清楚，那这个名字就起失败了

应该这样起名字：

• 名字要反映实际含义：Customer比data好，SaveToDatabase比Update清楚

• 要有明显区别：获取用户列表用getUsers()，获取单个用户用getUserById()

• 要方便读出来：generationTimestamp比genTs好，因为你可以直接念出来跟同事讨论

• 要方便搜索：作用域越大，名字应该越完整。全局常量MAX_CONNECTIONS_PER_SERVER比简单的MAX好找多了

第二，把函数写清楚

函数是组织代码的基本单位，写好了能让整个代码都好读。

函数要短小精悍：最好不超过20行，缩进不要超过两层。一个屏幕能看完的函数最舒服。

一个函数只做一件事：如果能从函数里抽出一个有意义的独立功能，那就应该抽出来。

告别巨大的switch语句：用多态来代替重复的switch/if-else。把switch逻辑封装在工厂类或策略模式里。

参数越少越好：
没有参数最好，一个参数不错，两个参数还行，三个参数就要考虑一下了。参数太多时，可以把它们封装成一个对象。

不要有副作用：函数名说做什么就只做什么。叫checkPassword的函数就不应该去初始化会话。副作用是bug的温床。

善用IDE的重构功能：比如Android Studio的Extract功能（Ctrl+Alt+M），可以帮你快速拆分长函数。

第三，注释要写得有用

最好的注释是不需要注释——代码本身已经说清楚了一切。

这些注释可以写：

• 解释为什么这么写：当代码因为某些限制不能写得更清楚时

• 提供额外信息：比如法律声明、版权信息、跟产品经理约定的特殊规则

• 警告后果：// 不要动！这个休眠是为了解决XX设备的竞态条件问题

• TODO注释：标记临时方案或计划要做的事，但要记得定期清理

这些注释不要写：

• 自言自语：注释比代码还难懂

• 过时的注释：代码改了注释没改，比没有注释更糟糕

• 修改日志：这是git该做的事，不是注释该做的事

• 废话注释：// 把名字设为"John"，然后下一行是user.setName("John")

• 被注释掉的代码：直接删掉！如果需要，可以从git历史里找回来

记住：不要为烂代码写注释，要去重构它！

第四，保持统一的代码风格

统一的格式能让阅读成本大大降低。

团队要用同一套标准：使用.editorconfig、IDE格式化模板等工具来保持统一。避免因为格式修改污染git blame信息。

限制每行长度：100-120个字符是常见标准，保持一行代码在屏幕上不用横向滚动。

代码要自上而下阅读：最上面是主逻辑，读起来像文章一样流畅，下面是具体实现细节。

合理使用空行：空行就像文章的分段，用来分隔不同的逻辑块。

相关代码放一起：关系紧密的代码应该靠近。变量定义要离使用的地方近，相关的函数要放在一起。

第五，处理好异常和边界情况

健壮的程序能够优雅地处理各种意外。

使用异常而不是错误码：错误码容易被忽略，而异常不可忽视。

把try/catch抽离出来：将错误处理逻辑封装成独立方法，让主逻辑更清晰。

不要返回null：返回空集合、空对象或者Optional，避免可怕的空指针异常。

谨慎使用受检异常：它破坏了封装性，导致所有调用者都要处理。优先考虑使用运行时异常。

处理第三方代码时：

• 隔离第三方代码：不要让你的代码里到处是第三方类的引用。为它们写适配层或包装类，把第三方代码控制在边界内。这样以后换库的时候影响范围就小多了。

• 通过阅读源码来学习：了解一个框架的边界和约定，可以看看它的源码，测试一下在什么情况下会抛出异常。

第六，把类整理清楚

类是更高层次的组织单位。

类要短小，职责要单一：一个类不应该变成什么都管的“上帝类”。一个警示信号是：类的公开方法超过5-7个。

遵守单一职责原则：一个类应该只有一个引起它变化的原因。如果一个类承担了太多职责，它就很容易变得臃肿和脆弱。

隔离变化：

• 依赖抽象：依赖接口而不是具体实现，这样更灵活

• 封装成员变量：不要暴露公有字段，使用getter/setter方法，方便以后添加控制逻辑

• 大胆拆分：不要怕类太多。多个职责单一的小类，远比一个巨无霸类要好

这就像是一个分类清晰的工具箱，每个工具各司其职，比把所有工具都扔进一个大麻袋好用多了。

总结

好的代码库应该像一个整理得井井有条的抽屉柜，每个抽屉里放什么东西都清清楚楚。而不是几个塞满杂物的大抽屉，想找什么都得翻个底朝天。

虽然看起来类的数量多了，但每个类都职责明确，找东西、用东西、改东西的成本都大大降低了。

写代码的时候，要时刻想着：如果别人来看这段代码，能不能很快看懂？如果明天要改需求，这里好不好改？抱着这样的心态写代码，你的代码质量自然就会提高。

记住，写出好代码不是一朝一夕的事，需要不断练习和反思。每次写代码时多想想，多改改，慢慢你就会发现，你的代码越来越清晰，越来越容易维护了。

本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！

链接: https://fly63.com/article/detial/12945