英文:
Go file names starting with underscore character
问题
我希望在我的编辑器的文件列表中，特定的文件出现在顶部，所以我在文件名前加了 _。它的样子是这样的：
mypkg
_func.go
a.go
b.go
我知道 Go 使用 _test、_unix 等命名约定，但是由于 _func 不符合特定的架构或者是一个测试用例，为什么它不算作源文件呢？
当我导入这个包时，这个文件中定义的函数是不可用的。
英文:
I wanted a specific file to appear at the top of my file list in my editor, so I prefixed it with _. This is how it looks:
mypkg
_func.go
a.go
b.go
I know about Go's file naming conventions using _test, _unix etc, however, since _func does not match a specific architecture or is a test case, why doesn't it count as source file?
When I import this package, functions defined in this file are not available.
答案1
得分: 14
显然，下划线和文件开头的点前缀在权重上是相同的，并且在go build命令中被完全忽略。然而，这不是go工具的决定，而是标准库中的go/build包的决定。你可以在这里看到相关的代码行。
我猜临时文件以下划线作为前缀，以便在构建工具链中被忽略。
编辑：这个评论记录了这种行为。我引用如下：
// Import返回指定导入路径的Go包的详细信息，将本地导入路径解释为相对于srcDir目录。
// 如果路径是一个本地导入路径，命名一个可以使用标准导入路径导入的包，返回的包将设置p.ImportPath为该路径。
//
// 在包所在的目录中，.go、.c、.h和.s文件被视为该包的一部分，除非：
//
// - 包文档中的.go文件
// - 以_或.开头的文件（可能是编辑器临时文件）
// - 具有上下文不满足的构建约束的文件
//
// 如果发生错误，Import返回一个非nil的错误和一个非nil的*Package，其中包含部分信息。
//
你可以在package go/build的包文档中以用户友好的形式找到这些信息。
英文:
Apparently, the underscore weights the same as the dot prefix at the beginning of files and is plainly ignored by the go build command. This however is not a decision of the go tool but of the go/build package in the standard library. You can see the responsible line here.
My guess is that temporary files are prefixed with underscores so that they are ignored by the build tool chain.
Edit: This comment documents the behavior. I cite:
// Import returns details about the Go package named by the import path,
// interpreting local import paths relative to the srcDir directory.
// If the path is a local import path naming a package that can be imported
// using a standard import path, the returned package will set p.ImportPath
// to that path.
//
// In the directory containing the package, .go, .c, .h, and .s files are
// considered part of the package except for:
//
// - .go files in package documentation
// - files starting with _ or . (likely editor temporary files)
// - files with build constraints not satisfied by the context
//
// If an error occurs, Import returns a non-nil error and a non-nil
// *Package containing partial information.
//
And you can find this in user friendly form in the package docs of package go/build.
答案2
得分: 2
我记得_whatever在go工具中的处理方式类似于shell中隐藏dotfiles（.whatever）。不幸的是，我找不到任何关于它在哪里有文档记录的参考资料。
所以，如果我没记错的话，你将不得不将源文件重命名，因为它与Go构建系统不兼容，除非你希望将_file.go视为某个包的一部分。
这种行为的目的可能是为了方便像CGO等工具创建临时和不冲突的文件。
英文:
I think I recall that _whatever is treated by the go tool in a similar fashion how dotfiles (.whatever) are hidden in the shell. Unfortunately, I cannot find any reference to where it is documented.
So, if my memory servers me correctly, you will have to rename the source file as it is not compatible with the Go build system in the case where you mean to have such _file.go considered a part of some package.
The intent for this behavior is probably to allow for easy creating temporary and non-conflicting files for tools like CGO etc.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论