在线安装SonarLint插件
-
File->Settings…进入设置界面
-
点击左侧Plugins，然后在搜索框输入SonarLint,点击安装，之后重启IDEA
离线安装SonarLint插件
-
在如下链接下载对应最新版本sonarlint
https://plugins.jetbrains.com/plugin/7973-sonarlint/versions -
File->Settings…->Plugins->点击设置按钮->在下拉框中点击Install Plugin from Disk…
-
找到之前压缩包的安装目录，点击安装包安装，重启IDEA即可。
代码质量分析报告模板
风吟博客开源代码的质量分析报告
该博客是基于SSM实现的个人博客系统，适合初学SSM和个人博客制作的同学学习。
最新版本支持用户注册，包含用户和管理员两个角色 。该博客规模适中，通过初步阅读分析其代码质量较高，故对其进行进一步的质量分析和审查。
一、代码质量分析方法
代码质量分析主要由人工分析和利用工具分析两种方式，二者各有优缺点，在实际过程中需要结合使用以保证正确性、发挥效能。
1、人工
通过人工发现代码中存在的缺陷和质量问题是分析软件质量最直接的手段。软件开发相关人员在软件实现、测试、维护过程中，主动发现编写代码中存在的问题并给予修改，但是分析代码的效率低，寻找缺陷不够全面，比如其中软件的深层次问题可能难以发现。
2、自动
利用SonarQube，FindBugs等工具进行代码质量分析，从程序的语法、结构、接口等方面进行代码审查，并能够对代码风格进行分析。其优点是代码分析效率高，且能够发现软件开发人员忽略的错误，在实际应用中要结合人工审查才能完全明确代码缺陷。
本报告主要使用SonarLint工具进行针对博客进行质量分析，辅以少量的人工分析。
二、Sonar及SonarQube简介
SonarQube软件是一种静态代码检查工具，采用B/S架构，帮助检查代码缺陷，改善代码质量，提高开发速度，通过插件形式，可以支持Java、C、C++、JavaScript等等二十几种编程语言的代码质量管理与检测。
Sonar客户端可以采用IDE插件、Sonar-Scanner插件、Ant插件和Maven插件方式，并通过各种不同的分析机制对项目源代码进行分析和扫描，并把分析扫描后的结果上传到Sonar的数据库，通过Sonar web界面对分析结果进行管理。
三、使用SonarLint进行分析
右键项目->点击SonarLint->点击Analyze with SonarLint
在风吟博客源代码中，共审查出86个文件中的436个问题，经过人工审查，其中大量的问题在于规范和代码的简洁性要求，重复的字符串文字使重构过程容易出错。总体来说，风吟博客的代码质量较为不错。
代码中的缺陷分为如下几个等级：
（1）Blocker：极有可能影响应用程序表现的错误；
（2）Critical：可能影响应用程序表现的错误和表示安全缺陷的问题；
（3）Major：严重影响开发者效率的质量缺陷；
（4）Minor：轻微影响开发者效率的质量缺陷；
（5）Info：不是错误或者质量缺陷。
现对代码存在的质量问题进行汇总统计，对严重程度为Blocker、Critical和Major的问题进行逐一的分析：
严重程度：Blocker
1.Tests should include assertions测试应该包括断言
没有断言的测试用例只能确保不抛出异常。除了基本的可运行性之外，它对被测代码的行为没有任何保证。
2.TestCases should contain tests测试用例应该包含测试
没有任何测试方法的 JUnit 测试用例是没有意义的。同样，测试目录中不应有名为 *Test、*Tests 或 *TestCase 的文件，但文件中不应有测试。做这些事情中的任何一件都可能导致有人认为未覆盖的类已经过测试。
严重程度：Critical
1.String literals should not be duplicated字符串文字不应重复
重复的字符串文字使重构过程容易出错，因为您必须确保更新所有出现的内容。另一方面，常量可以从很多地方引用，但只需要在一个地方更新。
2.Methods should not be empty 方法不应为空
一个方法没有方法体有几个原因：
这是一个无意的遗漏，应该修复以防止生产中出现意外行为。
它尚未或永远不会得到支持。在这种情况下，应该抛出 UnsupportedOperationException。
该方法是一个有意的空白覆盖。在这种情况下，嵌套注释应该解释空白覆盖的原因
3.“static” base class members should not be accessed via derived types不应通过派生类型访问“静态”基类成员
为了代码的清晰性，永远不应该使用派生类型的名称访问基类的静态成员。这样做会令人困惑，并且可能会产生存在两个不同静态成员的错觉
严重程度：Major
1.Raw types should not be used不应使用原始类型
不应在变量声明或返回值中使用原始（没有类型参数）泛型类型。这样做会绕过泛型类型检查，并将不安全代码的捕获推迟到运行时。
2.Restricted Identifiers should not be used as Identifiers限制标识符不应用作标识符
即使技术上可行，也不应将受限标识符用作标识符。这只是出于兼容性原因才可能，在 Java 代码中使用它是令人困惑的，应该避免。
3.Deprecated elements should have both the annotation and the Javadoc tag不推荐使用的元素应该同时具有注释和 Javadoc 标记
弃用应同时使用@Deprecated 注释和@deprecated Javadoc 标记进行标记。注释使 IDE 等工具能够在引用已弃用的元素时发出警告，并且该标记可用于解释何时被弃用、为什么以及应如何重构引用。
4.Sections of code should not be commented out 代码不应被注释掉
程序员不应注释掉代码，因为它会使程序膨胀并降低可读性。
未使用的代码应该被删除，如果需要，可以从源代码控制历史中检索。
- Empty arrays and collections should be returned instead of null应返回空数组和集合而不是 null
返回 null 而不是实际的数组、集合或映射会强制方法的调用者显式测试 null，从而使它们更复杂且可读性更低。
此外，在许多情况下，null 被用作空的同义词。
