代码风格监控

今天Mark一些之前看过的可以用来监控代码风格的插件或工具。

首先，所谓的监控代码风格可以理解为三个层次：

代码格式：是一些编写代码风格的约束，比如一个方法用“{+换行”还是“换行+{”，绝大部分是可以通过Ctrl+Alt+L（IDEA）惊醒自动优化的，这一部分可以理解为代码格式。

坏味道：可以理解为一些不好阅读的代码，比如一个方法过长，那么很有可能是设计的不合理，包含过多指责。那么就需要我们重新设计。再或者重复代码，冗余代码，都是坏味道。

隐藏的危险：这一部分可以理解为代码存在问题了，比如说初始为null的对象在某一个条件分支并没有赋值，之后调用其方法的时候就有可能产生Nullpoint的问题，导致代码出错的code。

那么为什么我们要监控优化或者统一管理一个团队的代码风格呢，我觉得有如下几个因素：

1）首先很多时候代码不是我们自己看的，需要团队合作，那么当你的代码需要别人review的时候，其中很多代码都是格式的改动，只有一两行涉及到功能change，无疑是给review的同事增加负担。所以当每个人的风格统一，或有校验插件约束就能解决这类问题。

2）最直接的因素就是代码的只管可读性变得更好。

3）有的时候我们最初的设计并不一定是一步到位的，比如说一个方法由于不断enhance变得越来越长，那么有可能他就需要重新设计，这个时候需要辅助的monitor帮我们发现这类问题。

4）有的隐藏的风险并不是我们在编码的时候能够发现的，这就是为什么几乎每个程序员都面对过NullPoint的Exception，辅助的监控能够帮我们避免这些问题。

那么我们可以通过什么方式去监控我们的代码呢，下面简单分享一些插件或者工具的特点：

首先以下介绍的几种监控方式，前两种是以插件的形式存在的，可以通过IDEA进行直接查询下载。Sonar也有其插件叫做Sonarlint，也是可以直接查找下载的，如果不能通过IDEA插件搜索找到，可以根据俄IDEA的版本从官晚上下载然后引用。

1）Alibaba Java Coding Guidelines

首先这个插件应该是使用了阿里的代码编写规范来约束的。通过右键运行Alibaba Java Coding Guidelines Analyze可以产生类似于如下结果：

左边显示的是代码中蕴含的一些问题，这里的问题可以包含我最早说的风格问题或者隐藏的错误，右边是一些简单描述。

这个插件的特点就是很好实施，然后可以用这种统一的代码规范去管理代码，但是有两个小小的问题，一个是如果我不清楚抛出来问题的原因我不能直接从页面上找到文档说明，要去网上搜索。还有就是感觉还有很多问题没有暴露出来，也就是规范的条件还是比较宽松的。

2）CheckStyle：

这个插件可以自定义代码格式标准的xml，比如可以应用Google或者Oricle的代码规范，或者自定义代码规范来进行校验。（当然这样的话应用那种规范，确定具体规则就成为了一项比较关键的工作）

如图是checkStyle的设置和运行显示部分（可以在编写代码时进行自动check）：

可以看出暴露的绝大部分问题是代码格式的问题，也就是我之前说过的可以用Ctrl+Alt+L解决的问题，当然具体的校验内容可以通过修改校验文件实现。缺点和Alibaba Java Coding Guidelines类似。

3）Sonar

首先介绍SonarLint这个插件，如下是它的运行结果：

可以看出他发现的问题比以上两种要更多，它不光进行了格式的校验，而且真的可以把代码中的坏味道和隐藏的问题发现出来。而且右边是抛出问题的具体解释以及对应的Demo和Solution，让developer能够一眼知道怎么去修正。当然他也是存在问题的，就是因为默认的规范可能太详细，如果要真正用起来可能要去重新选择哪些适用哪些不适用，这个是要花时间的。（如图是可以配置Rule的界面，右边也会显示具体rules的描述）

Sonar可以理解为一个代码管理的工具或者平台，直观的看起来如图：

只要进行合理的配置就能对各个项目的风格监控并进行统一管理，很直观并且能很快的锁定问题。（具体如何配置网上有很多教程这里不做具体说明）。配置好了之后只要在项目文件下运行mvn sonar:sonar \就可以将分析的结果呈现在Console上进行显示。虽然看起来很强大很好用，但是他也是存在问题的，就是实施成本。程序员在编码的时候，如果是运行时提醒可能会去check，但是如果要去Console去查看，可能会忽略这个工作。所以实施起来还需要一些约束。