Имена файлов Go, начинающиеся с символа подчеркивания
Я хотел, чтобы конкретный файл появился в верхней части моего списка файлов в моем редакторе, поэтому я префикс _
. Вот как это выглядит:
mypkg
_func.go
a.go
b.go
Я знаю о соглашениях об именах файлов Go с помощью _test
, _unix
etc, однако, с _func
не соответствует определенной архитектуре или является тестовым случаем, почему он не считается исходным файлом?
когда я импортирую этот пакет, функции, определенные в этом файле, недоступны.
2 ответов
по-видимому, подчеркивание весит столько же, сколько префикс точки в начале файлов и явно игнорируется , а в стандартной библиотеке. Вы можете увидеть ответственную строку здесь.
Я предполагаю, что временные файлы имеют префикс с подчеркиванием, чтобы они игнорировались цепочкой инструментов сборки.
Edit:комментарий документы поведение. Я привожу:
// 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.
//
и вы можете найти это в удобной для пользователя форме в пакет документов пакета go/build
.
кажется, я это помню _whatever
обрабатывается инструментом go аналогичным образом, как dotfiles (.whatever
) скрыты в оболочке. К сожалению, я не могу найти никаких ссылок на то, где это задокументировано.
Итак, если мои серверы памяти меня правильно, вам придется переименовать исходный файл, так как он не совместим с системой go build в случае, когда вы хотите иметь такой _file.go
считается частью некоторого пакета.
целью такого поведения, вероятно, является позвольте легко создавать временные и не конфликтующие файлы для таких инструментов, как CGO и т. д.