阿里工程师谈什么是好的代码？

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

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); } 
 } 

类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。

水平格式

要有适当的缩进和空格。

团队统一

通常，同一个团队的风格尽量保持一致。集团对于 Java 开发进行了非常详细的规范。(可点击下方阅读原文，了解更多内容)

类与函数

类和函数应短小，更短小

类和函数都不应该过长(集团要求函数长度最多不能超过 80 行)，过长的函数可读性一定差，往往也包含了大量重复的代码。

函数只做一件事(同一层次的事)

同一个函数的每条执行语句应该是统一层次的抽象。例如，我们经常会写一个函数需要给某个 DTO 赋值，然后再调用接口，接着返回结果。那么这个函数应该包含三步：DTO 赋值，调用接口，处理结果。如果函数中还包含了 DTO 赋值的具体操作，那么说明此函数的执行语句并不是在同一层次的抽象。

参数越少越好

参数越多的函数，调用时越麻烦。尽量保持参数数量足够少，最好是没有。

注释

别给糟糕的代码加注释，重构他

注释不能美化糟糕的代码。当企图使用注释前，先考虑是否可以通过调整结构，命名等操作，消除写注释的必要，往往这样做之后注释就多余了。

好的注释提供信息、表达意图、阐释、警告

我们经常遇到这样的情况：注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了，而注释并没有跟进变化。所以，注释最好提供一些代码没有的额外信息，展示自己的设计意图，而不是写具体如何实现。

删除掉注释的代码

git 等版本控制已经帮我们记录了代码的变更历史，没必要继续留着过时的代码，注释的代码也会对阅读等造成干扰。

错误处理

错误处理很重要，但他不能搞乱代码逻辑

错误处理应该集中在同一层处理，并且错误处理的函数最好不包含其他的业务逻辑代码，只需要处理错误信息即可。

抛出异常时提供足够多的环境和说明，方便排查问题

异常抛出时最好将执行的类名，关键数据，环境信息等均抛出，此时自定义的异常类就派上用场了，通过统一的一层处理异常，可以方便快速地定位到问题。

特例模型可消除异常控制或者 null 判断

大多数的异常都是来源于 NPE，有时候这个可以通过 Null Object 来消除掉。

尽量不要返回 null ，不要传 null 参数

不返回 null 和不传 null 也是为了尽量降低 NPE 的可能性。

讨论了好代码的必要条件，我们再来看看好代码的否定条件：什么不是好的代码。Kent Beck 使用味道来形容重构的时机，我认为当代码有坏味道的时候，也代表了其并不是好的代码。

代码的坏味道

重复

• 重复可能是软件中一切邪恶的根源。—— Robert C.Martin

Martin Fowler 也认为坏味道中首当其冲的就是重复代码。

很多时候，当我们消除了重复代码之后，发现代码就已经比原来整洁多了。

函数过长、类过大、参数过长

过长的函数解释能力、共享能力、选择能力都较差，也不易维护。

过大的类代表了类做了很多事情，也常常有过多的重复代码。

参数过长，不易理解，调用时也容易出错。

发散式变化、霰弹式修改、依恋情结

如果一个类不是单一职责的，则不同的变化可能都需要修改这个类，说明存在发散式变化，应考虑将不同的变化分离开。

如果某个变化需要修改多个类的方法，则说明存在霰弹式修改，应考虑将这些需要修改的方法放入同一个类。

如果函数对于某个类的兴趣高于了自己所处的类，说明存在依恋情结，应考虑将函数转移到他应有的类中。

数据泥团

有时候会发现三四个相同的字段，在多个类和函数中均出现，这时候说明有必要给这一组字段建立一个类，将其封装起来。

过多的 if…else 或者使用 switch

过多的 if…else 或者 switch ，都应该考虑用多态来替换掉。甚至有些人认为除个别情况外，代码中就不应该存在 if…else 。

本文首先一句话概括了我认为的好代码的必要条件：整洁，接着具体分析了整洁代码的特点，又分析了好代码的否定条件：什么样的代码不是好的代码。仅是本人的一些见解，希望对各位以后的编程有些许的帮助。

我认为仅仅编写出可运行的代码是远远不够的，还要时刻注意代码的整洁度，留下一些漂亮的代码，希望写的代码都能保留并运行 102 年!

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!