Go命令行工具
安装了Go语言的安装包后,就直接自带Go命令行工具。
# 查看当前安装的Golang版本
go version
# 查看go命令行工具的帮助信息
go help
Go命令行工具可以完成如下工作:
- 代码格式化
- 代码质量分析和修复
- 单元测试与性能测试
- 工程构建
- 代码文档的提取和展示
- 依赖包管理
- 执行其他的包含指令
代码风格
代码风格,是一个与人相关、与机器无关的问题。
代码风格的好坏,不影响编译器的工作,但是影响团队协同,影响代码的复用、演进以及缺陷修复。
强制性编码规范
命名
命名规则涉及变量
、常量
、全局函数
、结构
、接口
、方法
等的命名。
Go语言从语法层面进行了以下限定:任何需要对外暴露的名字必须以大写字母开头,不需要对外暴露的则应该以小写字母开头。
软件开发行业最流行的两种命名法分别为驼峰命名法和下划线法,Go语言明确宣告了拥护驼峰命名法
而排斥下划线法。
排列
Go语言甚至对代码的排列方式也进行了语法级别的检查,约定了代码块中花括号的明确摆放位置。
非强制性编码风格建议
使用go fmt
命令可以对代码进行格式化,例如:
# 格式化单个Golang源文件
go fmt hello.go
更详尽的用法可以查看:go help fmt
。
当然,这个工具并非只能一次格式化一个文件,比如不带任何参数直接运行go fmt
的话,可以直接格式化当前目录下的所有*.go
文件,或者也可以指定一个GOPATH中可以找到的包名。
远程import支持
Go语言不仅允许我们导入本地包,还支持在语言级别调用远程的包。
假如,有一个用于计算CRC32的包托管于Github,那么可以这样写:
package main
import (
"fmt"
"github.com/myteam/exp/crc32"
)
在执行go build
或者go install
之前,只需要加这么一句:go get github.com/myteam/exp/crc32
。
当执行完go get
之后,会在src
目录中看到github.com
目录,其中包含myteam/exp/crc32
目录。在crc32
中,就是该包的所有源代码。
也就是说,go
工具会自动获取位于远程的包源码,在随后的编译中,也会在pkg
目录中生成对应的.a
文件。
工程组织
GOPATH
Go命令行工具大部分功能其实不再针对当前目录,而是针对包名,于是如何才能定位到对应的源代码就落到了GOPATH
环境变量身上。
假设现在本地硬盘上有3个Go代码工程,分别为~/work/go-proj1
、~/work2/goproj2
和~/work3/go-proj3
,那么GOPATH
可以设置为如下内容:
export GOPATH=~/work/go-proj1:~/work2/goproj2:~/work3/go-proj3
经过这样的设置后,就可以在任意位置对以上的3个工程进行构建。
目录结构
一个完整的Go项目工程结构通常如下:
<calcproj>
- README
- LICENSE
- bin
- calc
- pkg
- <linux_amd64>
- simplemath.a
- src
- calc
- calc.go
- simplemath
- add.go
- add_test.go
- sqrt.go
- sqrt_test.go
Go语言工程不需要任何工程文件,一个比较完整的工程会在根目录处放置这样几个文本文件。
- README:简单介绍本项目目标和关键的注意事项,通常第一次使用时应该先阅读本文档。
- LICENSE:本工程采用的分发协议,所有开源项目通常都有这个文件。
一个标准的Go语言工程包含以下几个目录:src
、pkg
和bin
。
src
用于包含所有的源代码,这是Go命令行工具的一个强制的规则,而pkg
和bin
则无需手动创建,如果必要Go命令行工具在构建过程中会自动创建它们。
构建过程中Go命令行工具对包结构的理解完全依赖于src下面的目录结构。
文档管理
所谓的文档,更多的是指代码中的注释、函数、接口的输入、输出、功能和参数说明,这些对于后续的维护和复用有着至关重要的作用。
Go语言让开发者完全甩掉注释语法的包袱,专注于内容。
// Copyright 2011 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
/*
Package foo implements a set of simple mathematical functions. These comments are for
demonstration purpose only. Nothing more.
If you have any questions, please don’t hesitate to add yourself to
[email protected].
You can also visit golang.org for full Go documentation.
*/
package foo
import "fmt"
// Foo compares the two input values and returns the larger
// value. If the two values are equal, returns 0.
func Foo(a, b int) (ret int, err error) {
if a > b {
return a, nil
} else {
return b, nil
}
return 0, nil
}
// BUG(jack): #1: I'm sorry but this code has an issue to be solved.
// BUG(tom): #2: An issue assigned to another person.
如上代码文档示例中,添加了4条注释:版权说明注释、包说明注释、函数说明注释和最后添加的遗留问题说明。
关于注释的编写,要遵守如下的基本规则:
- 注释需要紧贴在对应的包声明和函数之前,不能有空行。
- 注释如果要新起一个段落,应该用一个空白注释行隔开,因为直接换行书写会被认为是正常的段内折行。
- 开发者可以直接在代码内用
// BUG(author):
的方式记录该代码片段中的遗留问题,这些遗留问题也会被抽取到文档中。
工程构建
使用go build
命令来执行构建,它会在你运行该命令的目录中生成工程的目标二进制文件,而不产生其他结果。
如果项目工程路径已经被加入到了全局变量GOPATH中,可以在任意位置执行go build
命令,而不必关心是否能找到源代码。
注意: 在构建可执行程序工程时,会在当前所在的目录中生成可执行程序,所以通常选择在项目目录下的bin目录中执行构建。
构建示例如下:
# calc是项目src目录下的包名
go build calc
单元测试
Golang本身提供了一套轻量级的测试框架,符合规则的测试代码会在运行测试时被自动识别并执行。
单元测试源文件的命名规则如下:在需要测试的包下面创建以“_test”结尾的go文件,形如[^.]*_test.go
。
Golang的单元测试函数分为两类:功能测试函数和性能测试函数,分别为以Test
和Benchmark
为函数名前缀并以*testing.T
或*testing.B
为单一参数的函数。
示例如下:
// 功能测试函数以Test为函数名前缀
func TestAdd1(t *testing.T)
// 性能测试函数以Benchmark为函数名前缀
func BenchmarkAdd1(t *testing.B)
测试工具会根据函数中的实际执行动作得到不同的测试结果:功能测试函数会根据测试代码执行过程中是否发生错误来返回不同的结果,而性能测试函数仅仅打印整个测试过程的花费时间。
功能单元测试
功能单元测试示例代码:
func TestAdd(t *testing.T) {
r := Add(1, 2)
if r != 3 {
t.Errorf("Add(1,2) failed. Got %d, expected 3.", r)
}
}
执行功能单元测试非常简单,直接执行go test
命令即可。
# 执行当前所在包的所有单元测试
go test
当然,也可以在IDE中对单个方法执行单元测试。
性能单元测试
性能单元测试示例代码:
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
Add(1, 2)
}
}
性能测试与功能测试代码相比,最大的区别在于代码里的这个for循环,写这个for循环的原因是为了能够让测试运行足够长的时间便于进行平均运行时间的计算。
如果测试代码中一些准备工作的时间太长,也可以这样处理以明确排除这些准备工作所花费时间对于性能测试的时间影响:
func BenchmarkAdd(b *testing.B) {
b.StopTimer() // 暂停计时器
DoPreparation() // 一个耗时较长的准备工作,比如读文件
b.StartTimer() // 开启计时器,之前的准备时间未计入总花费时间内
for i := 0; i < b.N; i++ {
Add(1, 2)
}
}
标签:语言,工程,代码,编程,单元测试,Go,go,目录
From: https://www.cnblogs.com/nuccch/p/17632558.html