代码提交检查 在代码提交之前,进行检查,如果不符合eslint则不予提交 安装依赖包 yarn add husky -D yarn add lint-staged -D yarn add eslint -D husky主要是触发钩子函数的,lint-staged主要是检查,eslint则是约束工具 在package.json文件中新增如下命令 "husky": { "hooks": { --fix", "precommit": "lint-staged" }, 配置好eslint规则之后,如果代码提交,有问题没解决,git会自动抛出错误,阻止提交代码 eslint相关规则说明 : 2, //不能对var声明的变量使用delete操作符 "no-dupe-keys": 2, //在创建对象字面量时不允许键重复 "no-duplicate-case": 2, // //在JSX属性中强制或禁止等号周围的空格 "no-unreachable": 1, //不能有无法执行的代码 "comma-dangle": 2, //对象字面量项尾不能有逗号
一.静态代码分析 静态代码分析是指在不允许程序的前提下,对源代码进行分析或检查,范围包括代码风格、可能出现的空指针、代码块大小、重复的代码等。 没有通过编译,静态代码分析就没有意义。 对于这样的问题很容易引起争议,如果公司对代码定标准,那符合与否不可能找一个人总盯着,开发组着虽然管理代码合并,也不可能逐行去看检查是否符合标准。 代码检查规范的方案是使用构建工具或者代码分析器进行代码检查,不通过,pipeline就中止。 二.规范检查 PMD进行检查 PMD(https://pmd.github.io)是一款可扩展的静态代码分析器,它不仅可以对代码风格进行检查,还可以检查设计、对线程、性能等方面的问题。 2.安装Jenkins PMD插件,作用是将PMD报告呈现在任务详情页中。
python哪儿都好,但是缩进太多,嵌套过多容易产生难以检查的语法错误,所以我们需要一款静态检查软件 这里引入一个静态检查利器: flake8. flake8介绍 它是以下三工具的包装: PyFlakes Pep8: 代码风格检查 Ned Batchelder’s McCabe script: 代码复杂度检查 三大功能: python代码风格检查,使工程项目满足良好的代码风格,容易发现问题。 一些基本的代码检查。 , 检查成功后才能提交. 推荐编辑器 Radon: 复杂度检查.
Golint(1)安装golintgit clone https://github.com/golang/lint.git cd lint/golintgo install(2)使用方式# 检查单个文件 URL Ip -> IP Sql -> SQL包命名统一小写不使用驼峰和下划线注释第一个单词要求是注释程序主体的名称,注释可选不是必须的外部可见程序实体不建议再加包名前缀if语句包含return时,后续代码不能包含在 golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.41.1golangci-lint --version(2) 使用方式# 检查单个文件golangci-lint run service.go # 指定目录golangci-lint run internal/ # 检查当前目录所有.go文件,会递归查找当前目录及子目录 codestyle# golang版本需要 >=1.6yum -y install graphvizgo get -u github.com/360EntSecGroup-Skylar/goreporter(2)
如果每次在代码提交之前都进行一次eslint代码检查,就不会因为某个字段未定义为undefined或null这样的错误而导致服务崩溃,可以有效的控制项目代码的质量。 "no-unused-vars":2 禁止出现未使用过的变量。 "no-use-before-define":2 不允许在变量定义之前使用它们。 "no-multiple-empty-lines": ["error", {"max": 2}] 空行不能够超过2行。 ESLint的检查。 因为在我们改代码的过程中去做一次检查,如果有错误,我们就能够很快地去定位到问题并解决问题。这时候我们可以借助eslint-loader插件。
根据项目整体代码检查结果,记录一下,有了这玩意,代码规范问题多犯犯错误,以后就没毛病了啊~ 1.不要使用SimpleDataFormat,它是线程不安全的类,可能导致线程安全问题,慎用 --可以使用DateTimeFormatter 代替SimpleDateFormat 原文地址,可以点这里 2.闲置不用的存储,包含无效变量,无效引用应该删除 闲置存储是给本地变量赋值,这个值可能是null或者在后续处理中不被使用的。
当应用程序需要访问网络时,它首先应该检查设备的网络状态,确认设备的网络环境及连接情况,并针对这些情况提醒用户做出相应的处理。 工欲善其事必先利器,在检查设备的网络状态前,我们要先实现两个步骤: 下载,添加Reachability类。 2. 为项目添加SystemConfiguration.framework框架。 注意:如果Reachability不是3.0以上的版本,而是Reachability 2.x版本,它是不支持ARC的。 核心实现代码: 1 // ViewController.m 2 // NetWorkDemo 3 // 4 // Copyright (c) 2014年 MiracleHe.
三.持续代码质量检测 SonarQube是一个代码质量管理工 具,能对20多种编程语言源码进行代码味道( Code Smells)、Bug、 安全漏洞方面的静态分析。 SonarQube服务默认允许任何人执行源码分析,因此在生产环境中使用会有安全隐患,以下几步可以提高其安全性: 1.设置SonarQube禁此非登录用户使用 2.为用户生成Token,Jenkins org.sonarsource.scanner.maven:sonar-maven- plugin:3.4.1.1168:sonar -Dsonar.host.url=http://192.168.1.8:9000 -Dsonar.login=e2f92b48d047be825fe3c2c06dec818788855a3e 具体步骤如下: 1.Jenkins安装SonarQube Scanner插件 2.Jenkins配置SonarQube Scanner插件 3.SonarQube设置Webhooks,不同代码规模的源码 可以看出它是针对新代码的。所以,在初次及没有新代码加入的情况下,执行代码分析是不会报出构建失败的。
,发现位于67个文件中的873个方法共有5138行代码是重复的。 进入正题,介绍一下Simian这个冗余代码检查工具,目前的版本是2.2.24,不光是c#代码,它也可以用来检查C, C++, COBOL, Ruby, JSP, ASP, HTML, XML, Visual Basic等格式的代码。 simian并非免费工具,如果你用它来检查开源代码或非商业代码的话,它是免费使用的,如果是商业应用的话,就需要付费了。 c#文件: "-includes=*.cs" 检查当前目录下的所有c#文件 ,并且只检查代码3行以上重复的代码 -threshold=3 "*.cs" 检查所有的c#文件: "*.cs" 使用命令行输出的话
下面是其纠正 js 代码的错误截图。
前言 OCLint是静态代码检查工具,用于检查代码质量 环境部署 网上太多类似教程,可参考 OCLint在Xcode中的使用 OCLint 实现 Code Review - 给你的代码提提质量 脚本 LONG_METHOD=200 \ -rc LONG_VARIABLE_NAME=40 \ -rc LONG_CLASS=3000 \ -max-priority-1=10000 \ -max-priority-2= workspace $myworkspace -scheme $myscheme clean&&xcodebuild -workspace $myworkspace -scheme $myscheme 2. 用oclint-json-compilation-database命令分析代码 -e 需要忽略分析的文件,这些文件的警告不会出现在报告中 -rc 需要覆盖的规则的阀值,这里可以自定义项目的阀值,默认阀值 默认阈值 CYCLOMATIC_COMPLEXITY 方法的循环复杂性(圈负责度) 10 LONG_CLASS C类或Objective-C接口,类别,协议和实现的行数 1000 LONG_LINE 一行代码的字符数
# 检查你的Python版本 from sys import version_info if version_info.major = 2 and version_info.minor !
通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具以及持续集成工具,与持续集成工具不同,Sonar 并不是简单地把不同的代码检查工具结果直接显示在 WEB页 面上,而是通过不同的插件对这些结果进行再加工处理 ,通过量化的方式度量代码质量的变化,从而可以方便的不同规模和种类的工程进行代码质量管理。 SONAR_SCANNER_HOME=C:\jenkins\sonar-scanner-4.7 PATH PATH=%PATH%;C:\jenkins\sonar-scanner-4.7\bin 打开cmd命令行,使用如下命令可以检查是否安装成功 项目配置 假设需要扫描的项目是 C:\jenkins\SpringBoot_v2 扫描其中的 src 目录 在 C:\jenkins\SpringBoot_v2 添加一个 sonar-project.properties 进行扫描 如果安装了 sonarQube 服务器就可以进行静态代码扫描了。
image.png 0x00 Xcheck介绍 Xcheck是一个由腾讯公司CSIG质量部代码安全检查团队自研的静态应用安全测试(SAST,Static application security testing )工具,致力于挖掘代码中隐藏的安全风险,提升代码安全质量。 Xcheck现已支持Golang、Java、Nodejs、PHP、Python 五种语言的安全检查,其他语言支持还在开发中。 在4核16g的linux云主机上,Xcheck对项目的检查速度在 1w+/s ,部分项目可以达到 2w+/s。以28w行的wordpress项目为例,xcheck检查时间为18s。 image.png 漏洞触发点: image.png 其中一条触发路由: image.png 2.
bug检查 Sonar Quabe 一站式代码质量审查平台 1. 考虑为了查看report,这里就不绑定生命周期,而是直接通过执行goal的方式来检查。 2.checkstyle,这个读取我们自定义的checkstyle的配置,后期在使用过程中修改完善程我们自己的配置方案。可以过滤不需要扫描的文件,比如生成的java文件。 阿里Java检查报告: ? checkstyle编码规范报告: ? 3 检查阈值 site命令会生成对应的report,但实际开发中,我们会期望出现错误时停止构建,提醒开发者修复问题。 也可以在检查的时候手动执行一下check。最终,我选择了手动check方案。
Flow Flow是Facebook开源的静态代码检查工具,他的作用是在运行代码之前对React组件以及Jsx语法进行静态代码的检查以发现一些可能存在的问题。 而Flow是静态检查,是在代码编译运行之前进行一次检查,两者相辅相成互不干扰。 Props参数检查 承接上面 MyComponent 的例子,我们引入Flow的注解对代码进行检查: // @flow // flow的例子,可以看看和PropType的差异在哪 import 第二栏[1]违反了[2]的限定,[3]违反了[4]的限定。我们将组件变更为<MyComponent num={2} text="2"/>即可检查通过。 个人觉得Flow除了开发人员自检还要整合到整个测试框架中,在集成测试或某个版本的代码发布之前进行集中检查。
使用line_profile模块 line_profile 给出了在你代码美一行花费cpu时间。 接下来测试该代码: $ kernprof -l -v + 要执行的代码 ? -l 标识表明了逐行和-v标识表明详细输出。 使用memory_profile模块 memory_profile模块被用于在逐行的基础上,测量你代码的内存使用率。尽管如此,它可能使得你的代码运行的更慢。 安装guppy: $ pip install guppy 然后将你的代码该改成如下: #! 通过以上几个模块,可以更加清晰的了解python代码的执行过程以及对资源的占用情况。对代码优化有很大的帮助
Verilog/SV代码检查器-Lint 建模规则检查器与 Verilator 绪论 硬件设计是无情的,因此使用可以获得的任何错误的软件都是值得的。 在进行综合之前,简单的检查自己代码的一些潜在问题,有助于减少后续调整的时间。 Verilator是一个 Verilog 仿真器和 C++ 编译器,它还支持 linting:静态分析设计问题(代码校验工具)。 从 Verilator 4.028 开始,可以创建避免检测文件来处理警告,而无需接触源代码。 Linting Shell 脚本 如果有许多顶级模块或包含很多目录,可以使用 Makefile 或简单的 shell 脚本自动检查。 以下 shell 脚本检查位于同一目录中的所有顶级模块: #!
概述 FindBugs 是一个静态分析工具,它检查类或者 JAR 文件,将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具,就可以在不实际运行程序的情况对软件进行分析。 FindBugs—代码缺陷分类 Badpractice:不好的做法,代码违反了公认的最佳实践标准; Maliciouscode vulnerability:恶意的代码漏洞; Correctness:正确性 ; Performance:潜在的性能问题; Security:安全性; Dodgycode:糟糕的代码,FindBugs团队认为该类型下的问题代码导致bug的可能性很高; Experimental:实验 *"/> <Class name="~.*\.Manifest\$.*"/> </Or> </Match> </FindBugsFilter> Step2: mhq=findbugs&mhsrc=ibmsearch_a https://www.ibm.com/developerworks/cn/java/j-findbug2/index.html?
Flow Flow是Facebook开源的静态代码检查工具,他的作用是在运行代码之前对React组件以及Jsx语法进行静态代码的检查以发现一些可能存在的问题。 而Flow是静态检查,是在代码编译运行之前进行一次检查,两者相辅相成互不干扰。 Props参数检查 承接上面 MyComponent 的例子,我们引入Flow的注解对代码进行检查: // @flow // flow的例子,可以看看和PropType的差异在哪 import 第二栏[1]违反了[2]的限定,[3]违反了[4]的限定。我们将组件变更为<MyComponent num={2} text="2"/>即可检查通过。 Flow除了开发人员自检还要整合到整个测试框架中,在集成测试或某个版本的代码发布之前进行集中检查。