英文:
Go library package names
问题
我对外部Go库的包命名有一些问题。
我想知道是否使用像" text
"这样的通用名称被认为是一种良好的做法?考虑到我不能声明一个"嵌套包",而且我正在构建的库涉及文本处理,将包命名为" text
"是否可以,还是应该将库名称作为包名称?
我正在构建一组库(不同的项目),我希望将它们组合在同一个包中。这样做是否也有问题?我是Go社区的新手,还不确定包污染是否是一个问题(只要在我的代码中导入少量包,我认为没有问题)。
英文:
I have some questions on package naming for external Go libraries.
I am interested if using generic names like "text
" is considered a good practice? Having in mind that I cannot declare a "nested package" and that the library I am building deals with text processing, is it ok to have the package named "text
" or should I stick to the library name as a package name too?
I am building a set of libraries (different projects) and I want to combine them under the same package. Is this also problematic? I am new to the Go community and am still not sure if package pollution is a problem or not (I do not see a problem as long as I import few packages in my code).
答案1
得分: 10
关于命名主题的参考资料是"博客:包名"
其中包括:
避免不必要的包名冲突。
虽然不同目录中的包可能具有相同的名称,但经常一起使用的包应具有不同的名称。这样可以减少混淆和客户端代码中的本地重命名的需求。出于同样的原因,避免使用与常用标准包(如io或http)相同的名称。
还要检查一下你的包发布实践,这将有助于将你的“text
”包与其他包区分开来。
正如在“Go编程简介/包”中所示:
math
是Go标准发行版中的一个包的名称,但由于Go包可以是分层的,我们可以安全地使用相同的名称作为我们的包。(真正的math包只是math,我们的是golang-book/chapter11/math
)
当我们导入我们的
math
库时,我们使用它的完整名称(import "golang-book/chapter11/math"
),但在math.go
文件中,我们只使用名称的最后一部分(package math
)。
当我们引用我们库中的函数时,我们也只使用短名称math。如果我们想在同一个程序中使用两个库,Go允许我们使用别名:
import m "golang-book/chapter11/math"
func main() {
xs := []float64{1,2,3,4}
avg := m.Average(xs)
fmt.Println(avg)
}
m
是别名。
正如elithrar在评论中提到的,Dave Cheney还有一些额外的建议:
在其他语言中,通过在包名前加上公司名称,例如
com.sun.misc.Unsafe
,确保包具有唯一的命名空间是相当常见的做法。
如果每个人只编写与他们控制的域相对应的包,那么几乎不可能发生冲突。
在Go中,惯例是在包的导入路径中包含源代码的位置,例如
$GOPATH/src/github.com/golang/glog
这不是语言要求的,只是
go get
的一个特性。
英文:
The reference on that naming topic is "blog: Package names"
It includes:
> Avoid unnecessary package name collisions.
While packages in different directories may have the same name, packages that are frequently used together should have distinct names. This reduces confusion and the need for local renaming in client code. For the same reason, avoid using the same name as popular standard packages like io or http.
Check also your package publishing practice, as it will help disambiguate your "text
" package from others.
As illustrated in "An Introduction to Programming in Go / Packages":
> math
is the name of a package that is part of Go's standard distribution, but since Go packages can be hierarchical we are safe to use the same name for our package. (The real math package is just math, ours is golang-book/chapter11/math
)
> When we import our math
library we use its full name (import "golang-book/chapter11/math"
), but inside of the math.go
file we only use the last part of the name (package math
).
> We also only use the short name math when we reference functions from our library. If we wanted to use both libraries in the same program Go allows us to use an alias:
import m "golang-book/chapter11/math"
func main() {
xs := []float64{1,2,3,4}
avg := m.Average(xs)
fmt.Println(avg)
}
> m
is the alias.
As mentioned in the comments by elithrar, Dave Cheney has some additional tips:
> In other languages it is quite common to ensure your package has a unique namespace by prefixing it with your company name, say com.sun.misc.Unsafe
.
If everyone only writes packages corresponding to domains that they control, then there is little possibility of a collision.
> In Go, the convention is to include the location of the source code in the package’s import path, ie
$GOPATH/src/github.com/golang/glog
> This is not required by the language, it is just a feature of go get
.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论