SonarQube安全扫描常见问题

本文主要是介绍SonarQube安全扫描常见问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、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.ContextLogger             *zap.SugaredLoggerJob                *models.JobAppImage           stringEnvVars            map[string]stringSchedulerSubmitFlags map[string]stringNoTransfer         boolLocalImage         boolCoresPerNode       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”标签的使用