目录
一、SonarQube质量报告
二、SonarQube扫描常见问题和修复方法
三、SonarQube质量配置
最近小编在使用SonarQube工具进行代码扫描，检查代码异味，系统漏洞等，实际过程中也遇到了不少问题，这篇文章主要列举我遇到的常见问题和解决方法。
如何使用SonarQube进行安全扫描，可以查看往期文章：SonarQube安全扫描_sonarqube 安全扫描-CSDN博客
一、SonarQube质量报告
进入到SonarQube首页，可以看到项目报告的全部信息，如下图所示：
点击项目名称，可查看报告详情，New Code（新增代码）Overall Code（全量代码）
二、SonarQube扫描常见问题和修复方法
1.（不应重复字符串文字）String literals should not be duplicated.
问题分析：重复输出某个文字
解决方法：定义一个常量来代替重复的字面值
上述代码可修改为：
const errmsg = "check request fields required failed, %w"
err, errResp := CheckRequestFieldsRequired(req, reflect.TypeOf(*req))
if err != nil {
return fmt.Errorf(errmsg, err), errResp
}2.（认知功能的复杂度不应过高）Cognitive Complexity of functions should not be too high.
问题分析：代码复杂度过高
解决方法：将封装的函数可以拆分成多个函数，其实每个if...else...或者for语句都可以根据代码需求封装为函数，降低代码复杂度。
3.（函数不能为空）Functions should not be empty.
问题分析：函数为空
解决方法：首先确定函数体为空的原因，可能的点：预留的钩子，实现接口所必需，遗漏实现功能。
如果是预留的狗子或者满足接口的需要可以在函数内添加注释，说明当前的情况和未来可能的计划。
如果是遗漏了某个功能的实现，根据实际需求补充相关的逻辑。
4.（函数不应该有太多的参数）Functions should not have too many parameters.
问题分析：函数存在过多的参数，增加了调用该函数的复杂性，同时也降低了代码的可读性和可维护性。
解决方法：可以使用参数对象模式，创建一个包含所有这些参数的新结构体类型，可以减少函数的参数数量。
上述代码可修改为：
type AssembleHPCJobRequestParams struct {
Context context.Context
Logger *zap.SugaredLogger
Job *models.Job
AppImage string
EnvVars map[string]string
SchedulerSubmitFlags map[string]string
NoTransfer bool
LocalImage bool
CoresPerNode int
}
func AssembleHPCJobRequest(params AssembleHPCJobRequestParams) hpc.SystemPostRequest {
// 函数的实现逻辑...
}
//在调用这个函数的时候
params := AssembleHPCJobRequestParams{
Context: ctx,
Logger: logger,
Job: job,
AppImage: appImage,
EnvVars: envVars,
SchedulerSubmitFlags: schedulerSubmitFlags,
NoTransfer: noTransfer,
LocalImage: localImage,
CoresPerNode: coresPerNode,
}
request := AssembleHPCJobRequest(params)5.（局部变量和函数参数名称应遵守命名约定）Local variable and function parameter names should comply with a naming convention.
问题分析：此局部变量命名不符合正则表达式
解决方法： 上述命名其实已经符合正则表达式规则，但是按照常见的Go语言命名习惯，变量名一般采用驼峰式命名（CamelCase），而非下划线分隔。
上述命名可修改为：可以将user_combo更名为userCombo，将turn_info_each更名为turnInfoEach
三、SonarQube质量配置
| 质量规则 |
go:Sonar way Bug:6 坏味道:17
| ||
| 规则 | 类型 | 违规级别 | 中文 |
|
Variables should not be self-assigned
| Bug | 主要 | 变量不应自赋值 |
|
Identical expressions should not be used on both sides of a binary operator
| Bug | 主要 | 不应在二元运算符的两侧使用相同的表达式 |
|
All code should be reachable
| Bug | 主要 | 所有代码都应该是可访问的 |
|
Related "if/else if" statements should not have
the same condition
| Bug | 主要 | 相关的“if/elseif'语句不应具有相同的条件 |
|
"=+" should not be used instead of "+="
| Bug | 主要 | 不能用“=+”代替“+=” |
|
All branches in a conditional structure should not have exactly the same implementation
| Bug | 主要 | 条件结构中的所有分支都不应有完全相同的实现 |
|
Cognitive Complexity of functions should not be too high
|
坏味道
| 严重 | 认知功能的复杂度不应过高 |
|
String literals should not be duplicated
| 坏味道 | 严重 | 不应重复字符串文字 |
|
Functions should not be empty
| 坏味道 | 严重 | 函数不能为空 |
|
Track uses of "FIXME" tags
| 坏味道 | 主要 | 跟踪"FIXME"标签的使用情况 |
|
Two branches in a conditional structure should
not have exactly the same implementation
| 坏味道 | 主要 | 条件结构中的两个分支不应该有完全相同的实现 |
|
Redundant pairs of parentheses should be
removed
| 坏味道 | 主要 | 应删除多余的圆括号对 |
|
Functions should not have identical
implementations
| 坏味道 | 主要 | 函数不应该有相同的实现 |
|
Track parsing failures
| 坏味道 | 主要 | 跟踪解析失败 |
|
"switch" statements should not have too many
"case" clauses
| 坏味道 | 主要 | "switch"语句不应该有太多的"case"从句 |
|
Functions should not have too many parameters
| 坏味道 | 主要 | 函数不应该有太多的参数 |
|
Nested blocks of code should not be left empty
| 坏味道 | 主要 | 嵌套的代码块不应为空 |
|
Multi-line comments should not be empty
| 坏味道 | 次要 | 多行注释不应为空 |
|
Boolean checks should not be inverted
| 坏味道 | 次要 | 布尔值检查不应倒置 |
|
Boolean literals should not be redundant
| 坏味道 | 次要 | 布尔字面值不应是多余的 |
|
Function and method names should comply with a naming convention
| 坏味道 | 次要 | 函数和方法的名称应符合 命名约定 |
|
Local variable and function parameter names
should comply with a naming convention
| 坏味道 | 次要 | 局部变量和函数参数名称应遵守命名约定 |
|
Track uses of "TODO" tags
| 坏味道 | 提示 | 跟踪“TODO”标签的使用 |
经过上述分享，应该对SonarQube工具进行安全扫描和解决代码异味有了一定的了解，请继续关注小编~带来更多的分享哦~
