github 检查代码质量_如何提升开源项目的代码质量？

我们在github上面浏览开源项目的时候，经常可以看到一些小图标badge。这些图标往往暗示了该项目的代码质量，下面以我给gorazor项目添加的badge为例，逐一讲解一下：

本文虽然是以go项目为例，但像持续集成、lint、测试覆盖率、甚至cyclomatic complexities等分析，其它语言也会有相应工具的。

持续集成 build

大部分项目都可能会附带上build的标签，这个标签是意味着项目是否能经过持续集成的编译；一般上，github上的项目持续集成都是通过travis.org提供的免费服务来做。

travis的使用非常简单，只要在项目的根目录中添加一个.travis.yml配置文件，github就会在每次有代码提交的时候自动触发编译、持续集成，gorazor使用的配置文件是这样

# 说明这个是一个go项目language:go​# 指定待测试的go版本go:- "1.10"- "1.11"- "1.12.1"- "1.12.6"​# 安装依赖，这里只是测试gorazor本身能否被编译、安装install:- go get github.com/sipin/gorazor​# 触发 go test的测试脚本script:- go test -v ./pkg/razorcore/

travis的集成非常快，一般能够在分钟级别搞定。

持续集成是很好的保障，我有时会“闭着眼睛”直接提交我认为绝对不会错的代码修改去master分支，然后travis就给我报错了：

往往都是些完全出乎我意料的原因，像上面的错误，就是因为我本地的开发环境是windows，git忽略了我的目录名大小写修改；而到travis的linux docker中就有问题；彻底换个新目录名就可以解决。

go 版本

各个go版本亦会有区别，像我在gorazor中使用strings.Builder，这是go 1.10中才添加的标准库，所以我会指定最低从go 1.10开始测起，最新的go 1.12，我则会指定最早跟最新的两个小版本。

一般情况下，除非使用了新的标准库API，否则编译都能通过，而编译通过往往也就意味着测试成功。

gorazor为了追求成为世界最快的模板引擎，利用go编译器进行了特殊优化，这部分优化使用的编译器接口虽然在go 1.12跟go 1.11完全一致，并且release notes中完全没有提及；但go其实默默的改了内部实现！

这就造成同样的代码go 1.12可以优化；但go 1.11以及go 1.10的所有子版本则不行。

如果不是travis中指定了go的各个版本，我是不可能发现这些细节的；最后，我只好把模板编译优化的代码的测试案例独立出来，然后通过编译标签指定只有go 1.12才进行测试：

// +build go1.12​

package razorcore

​

func TestGenerateOpt(t *testing.T) {

...

}

Go Report Card

Go Report Card是一系列代码静态分析工具的集合：

这系列工具可以安装到本地运行、检查；但似乎跟线上版本会有小出入。

要获得A/A+的等级评分不难；但全部做到100%评分，0 issues，其实蛮有挑战性。

gofmt

这个一般使用VS Code的编辑器保存代码的时候，自动调用go fmt / go imports / go returns等格式化工具就可以了。

但Go Report Card绑定的go fmt格式化还会指定-s参数，即对代码进行简化，如果不是Go Report Card的提示，我确实没留意gorazor的中代码还能这样简化：

go vet

go vet其实也是go 内置的工具，它会对代码做进一步的检查，报告可疑的代码，比方说，Printf中的参数与格式化字符串不符。

VS Code官方的go插件默认也是会调用go vet；所以一般使用使用VS Code写出来的代码都不会有问题：

gocyclo

gocyclo是分析go 代码的cyclomatic complexities，即循环复杂度。

循环在这里翻译似乎不够准确，具体的说，它是分析代码函数中嵌套、条件分支的复杂程度。

如果出现callback hell：

或者大量的if / switch条件判断，那么这块就过不去：

像gorazor这样的带有parser的项目，还是蛮容易出现大量switch case的，但也确实可以重构：

重构之后虽然“变短”，但相应的是增加了函数调用层次；具体到parser的这个案例，我其实觉得用switch case的代码更加直观，阅读性更高，我会更喜欢。

这块如果做得好，万一写出《太吾绘卷》这样的爆款，也不用担心代码被吐槽啦~

gocyclo这块做到100%，花了我不少时间，但重构之后，代码的整体的可阅读性确实会提升一些；就是投入产出比不够高罢了~

golint

这个也是VS Code Go插件内置的；很多语言都有lint工具；这个主要是做代码风格的检查。

像变量名大小写啦~有没有注释啦~等等等~

这块要做到100%，虽然也是繁琐，但改起来比满足gocyclo快多了~

license

即检查项目是否包含版权信息，这块对于程序员来说，其实是非常重要的！！！

我之前就果断给gorazor加了996.icu的授权信息：关爱程序员，你我有责。

^_^

ineffassign

ineffassign是检查代码中无效的赋值；确实帮我找到了一些多余代码。

有时在代码中做了无脑赋值，赋值之后却没有做进一步调用，ineffassign都会找出来：

像上面这个hasBodyClosed，在函数前面的部分是需要赋值并检查的；但439行这里已经是对于hasBodyClosed的最后一次检查，自然无需再做任何赋值。

misspell

misspell会检查代码、注释中错误拼写的单词。

Go Coverage

这是检查代码单元测试的覆盖率；go代码能做到90%，我觉得已经很尽力了：

剩余的10%主要是因为很多错误分支的代码没有被覆盖：

要追求代码覆盖率KPI，做到100%覆盖倒是很简单，我把所有的err都吞掉就好了。

但这显然是会减低代码的健壮性！得不偿失。

可能等go 的try语法实现之后，就能做到100%吧~ ^_^

996.icu

重要的事情说三遍：关爱程序员，你我有责。

关爱程序员，你我有责。

求Star

觉得本文有帮助的程序员童鞋，给gorazor star一下可好？