【转】阿里工程师告诉你：什么是好的代码？

最新推荐文章于 2024-11-13 20:43:20 发布

Click#593

最新推荐文章于 2024-11-13 20:43:20 发布

阅读量146

点赞数

分类专栏：笔记文章标签： java

原文链接：https://mp.weixin.qq.com/s/AjubL4vVhFa_FIlaopLVCA

版权

笔记专栏收录该内容

2 篇文章 0 订阅

订阅专栏

本文探讨了什么是好的代码，强调整洁、高内聚低耦合、可读性，列举了衡量标准和不良代码特征。作者引用Bob大叔的观点，提出WTF/min作为评估标准，并提供了命名、格式、注释和错误处理等方面的建议，以及如何识别和改进坏代码。

摘要由CSDN通过智能技术生成

在这里插入图片描述

导读：我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。

一句话概括

衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin

在这里插入图片描述

Bob大叔对于好代码的理解非常有趣，对我也有很大的启发。我们编写的代码，除了用于机器执行产生我们预期的效果以外，更多的时候是给人读的，这个读代码的可能是后来的维护人员，更多时候是一段时间后的作者本人。

我敢打赌每个人都遇到过这样的情况：过几周或者几个月之后，再看到自己写的代码，感觉一团糟，不禁怀疑人生。

我们自己写的代码，一段时间后自己看尚且如此，更别提拿给别人看了。

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler

所以，谈到好代码，首先跳入自己脑子里的一个词就是：整洁。

好的代码一定是整洁的，给阅读的人一种如沐春风，赏心悦目的感觉。

整洁的代码如同优美的散文。—— Grady Booch

好代码的特性

很难给好的代码下一个定义，相信很多人跟我一样不会认为整洁的代码就一定是好代码，但好代码一定是整洁的，整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的，也一定是可读性强、易维护的。

高内聚低耦合

高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：

开闭原则 OCP (The Open-Close Principle)
单一职责原则 SRP (Single Responsibility Principle)
依赖倒置原则 DIP (Dependence Inversion Principle)
最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)
接口隔离原则 ISP (Interface Segregation Principle)
组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)

这些原则想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性。换句话说，我们可以用这些原则来衡量代码的优劣。

但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。只要打破原则的理由足够充分，也并不见得是坏的代码。

可读性

代码只要具有了高内聚和低耦合就足够好了吗？并不见得，我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码，提高可读性。

命名

大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。

► 名副其实

好的名称一定是名副其实的，不需要注释解释即可明白其含义的。

  /**
  * 创建后的天数
  **/
  int d;

  int daysSinceCreation;

后者比前者的命名要好很多，阅读者一下子就明白了变量的意思。

► 容易区分

我们很容易就会写下非常相近的方法名，仅从名称无法区分两者到底有啥区别（eg. getAccount()与getAccountInfo()），这样在调用时也很难抉择要用哪个，需要去看实现的代码才能确定。

► 可读的

名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写。

► 足够短

名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。

格式

良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。

► 垂直格式

通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。

public class Demo {

    @Resource

    private List<Handler> handlerList;

    private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>();



    @PostConstruct

    private void init() {

        if (!CollectionUtils.isEmpty(handlerList)) {

            for (Handler handler : handlerList) {

                handlerMap.put(handler.getType(), handler);

            }

        }

    }



    publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) {

        Handler handler = handlerMap.get(typeEnum);

        if (null == handler) {

            return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE);

        }

        return handler.query(id);

    }

}

如果去掉了空行，可读性大大降低。

  public class Demo {

      @Resource

      private List<Handler> handlerList;

      private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>();

      @PostConstruct

      private void init() {

          if (!CollectionUtils.isEmpty(handlerList)) {

              for (Handler handler : handlerList) {

                  handlerMap.put(handler.getType(), handler); } } }

      public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) {

          Handler handler = handlerMap.get(typeEnum);

          if (null == handler) {

              return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE);

          }

          return handler.query(id); }

  }