sonarqube如何导入规则 您所在的位置:网站首页 checkstyle自定义规则 sonarqube如何导入规则

sonarqube如何导入规则

2023-10-18 05:31| 来源: 网络整理| 查看: 265

4ab6ebbc173ddb408f534f56765c5d78.png

你好,欢迎收听极客视点。

对于一个软件开发团队,可以通过哪些代码质量指标和扫描方法让团队产出规范、安全、高质量的代码?公众号“ThoughtWorks洞见”的一篇文章总结了其中一些实践和工具,极客视点摘录了“代码质量扫描工具”和“代码质量指标”这两部分的内容分享给你,希望对你有所帮助。

代码质量扫描工具 1. Checkstyle

这是常用于 Java 项目的扫描工具,检查源代码是否与代码规范相符,检查项目主要包括:Javadoc 注释、imports、过长的类和方法、空格、重复文件、圈复杂度等,默认使用 sun 的代码规则,也可以配置自定义的代码规则,例如阿里就发布了相应的检查规则。

2. FindBugs

通过 Bug Patterns 的概念,寻找代码中可能出现的 Bug,检查项目主要包括:不良编程习惯导致的问题、性能问题、安全问题、线程问题等。例如,应使用 equals 判断相等,而不是 “ =” 操作符、流需要关闭、线程资源需要释放等问题。FindBugs 的模式库对编程经验也有较好的提升作用,还可以导入和编写自己的 Bug Patterns 完善检查机制。

3. Simian

这是一个用于检查重复和相似代码的工具,它的重复检查类似于论文查重,会提示一定的相似度。可以单独运行,也可以作为 Checkstyle 插件来使用,相对来来说比较小众。

4. PMD

这是一款跨语言的通用静态扫描工具,具备一部分 Checkstyle、FindBugs 的功能,不再赘述。

5. ESlint/TSlint

前端界的 Checkstyle , TSlint 设计用来做 TypeScript 类型检查,ESlint 作为代码风格检查工具。不过现在 ESlint 也提供了TypeScript 类型检查功能,基本上 ESlint 能整合这两个功能。由于性能问题,TypeScript 也采用了 ESLint 作为 TSlint替代的检查工具。

6. SonarQube

SonarQube 是一款用于代码质量管理的开源工具,它主要用于管理源代码的质量。SonarQube 和上面的工具不太一样,SonarQube 设计目的是提供一个平台,通过插件的方式提供对各个语言进行支持,也可以和 Checkstyle、PMD、Simian 等工具进行集成。SonarQube 一般需要单独部署成一个服务,提供数据库,可以记录扫描结果等信息。

7. npm audit

npm audit 是 npm 6 之后的版本自带的一个前端安全扫描工具,可以扫描 npm 依赖中的潜在的漏洞威胁。这些引入的漏洞可能威胁用户开发的机,另外也可能被带入 bundle 文件发布到线上,带来安全问题。目前 npm audit 会在 npm install 完成后自动执行,需要留意安全威胁报告。

8. Fortify SCA

Fortify SCA(Source Code Analyzer) 是一款非常优秀的代码安全扫描工具,用于分析代码中潜在的安全问题。通过调用语言的编译器或者解释器把代码(Java、C、C++等源代码)转换成一种中间媒体文件 NST(Normal Syntax Trcc),然后通过模式匹配相关的方式抓取存在于漏洞库中的漏洞。例如,上传的文件没有做检查等 XSS 攻击。

9. OWASP Dependency-Track

开放式 Web 应用程序安全项目(OWASP)是一个非营利组织,提供了很多安全标准、数据库、社区和培训。其中一个工具就是 OWASP Dependency-Track,可以对第三方依赖包中的知名漏洞进行检查,扫描结果受到漏洞数据库的更新影响。

10. Archunit 架构规范检查

前面的检查是代码层面,archunit 可以用于代码架构检查,可以定义规则检查每个包中的实现是否符合规范。例如,controller 包中的类不能实现 service 的接口,repository 下的类必须实现 Repository 接口。通过 Archunit 可以减少 Code Review 的工作量,避免项目的结构被破坏。

常用代码质量指标参考

1. 编译告警数。大部分程序员基本上忽略 warning,但是编译器出现告警是一种不好的体现,意味着软件可能工作,但是存在不好的实践。而这种不确定性,会带来不确定的 Bug,最终让人一头雾水。编译过程中的告警,尽量消除掉,编译告警的值推荐消除到 0。

2. 平均函数代码行数。过大的函数会导致阅读困难,而且往往过大的函数职责不够单一,一般将一个方法代码行数控制到 30 - 50 行。

3. 平均文件代码行。和平均函数代码行一样,过长的文件一样难以维护,一般一个文件10多个方法,因此文件的代码行数一般控制到 300 - 500 行。

4. 冗余代码。有时候我们代码中可能存在未使用的方法、变量等代码,这让维护者一头雾水,通常需要清零。

5. 总文件重复率,即出现重复文件的次数。除了编写单元测试的情况下,业务代码不应该出现重复代码,推荐值为 0。

6. 总代码重复度。代码的重复度检查,限于扫描工具的识别模式,需要有一定的容忍度,推荐值在 5% - 10%

7. 平均函数圈复杂度。圈复杂度用来衡量一个模块判定结构的复杂程度。如果一个方法内部有大量的 if 语句嵌套,意味着这个方法的实现质量低下,且程序复杂度高不利于维护,推荐值小于 5%。

8. 安全告警。如果配置了安全扫描工具,例如 Fortify,安全威胁应该被清零。

9. 代码缺陷。如果配置了缺陷扫描工具,例如 Findbugs,需要清零。

以上就是今天的内容,希望对你有所帮助。

e804f6800461813554744c13395f5c74.png


【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

      专题文章
        CopyRight 2018-2019 实验室设备网 版权所有