SonarQube安全扫描常见问题

目录

一、SonarQube质量报告

二、SonarQube扫描常见问题和修复方法

三、SonarQube质量配置


最近小编在使用SonarQube工具进行代码扫描,检查代码异味,系统漏洞等,实际过程中也遇到了不少问题,这篇文章主要列举我遇到的常见问题和解决方法。

如何使用SonarQube进行安全扫描,可以查看往期文章:SonarQube安全扫描_sonarqube 安全扫描-CSDN博客

一、SonarQube质量报告

进入到SonarQube首页,可以看到项目报告的全部信息,如下图所示:

点击项目名称,可查看报告详情,New Code(新增代码)Overall Code(全量代码)


二、SonarQube扫描常见问题和修复方法

1.(不应重复字符串文字)String literals should not be duplicated.

问题分析:重复输出某个文字

解决方法:定义一个常量来代替重复的字面值

上述代码可修改为:

Go 复制代码
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.

问题分析:函数存在过多的参数,增加了调用该函数的复杂性,同时也降低了代码的可读性和可维护性。

解决方法:可以使用参数对象模式,创建一个包含所有这些参数的新结构体类型,可以减少函数的参数数量。

上述代码可修改为:

Go 复制代码
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工具进行安全扫描和解决代码异味有了一定的了解,请继续关注小编~带来更多的分享哦~

相关推荐
名字还没想好☜4 分钟前
Python 的 __call__ 实战:让实例像函数一样被调用,做带状态计数器、缓存器与可配置策略
开发语言·后端·python·缓存·编程语言
skywalk81636 分钟前
第 23 轮方向确定:保护表通用化替代轮。先深入探查剩余保护表依赖场景和任务 6 的四阶段路径,再写任务书。9.14
开发语言·人工智能·光明
杨利杰YJlio12 分钟前
ITSK PE 26U5 测试版解读:组件完善、VMD 修复与服务器支持边界
前端·javascript·后端
PragmaticWorks12 分钟前
充血模型该充到什么地步?
后端·领域驱动设计
無限進步D13 分钟前
VSCode 简介+安装+JavaWeb前端常用插件+简单配置
java·开发语言·css·vscode·html·css3·插件
张小姐的猫16 分钟前
【AI大模型接入SDK】 —— SQLite上手
linux·开发语言·c++·人工智能·python·log4j
雨辰AI18 分钟前
信创多租户项目 9 大踩坑|数据隔离失效、权限越权终极解决(金仓 / 达梦 / 高斯全库适配)
java·大数据·数据库·后端
广州山泉婚姻22 分钟前
微服务时代,前后端分离架构该怎样高效协同?
前端·后端
孙启超23 分钟前
【AI开发之Rust】第 5 课:引用与生命周期 —— 借用能活多久?
人工智能·后端·rust·llm·ai应用开发
EatFan26 分钟前
多租户系统到底怎么设计?从 tenant_id 到 JWT 租户隔离的真实实践
前端·后端·全栈·多租户