将 go 文件放在模块路径上是一个好习惯吗？

Question

I find some project put go file on the module path. For example:

• v2ray-core put core.go file on the module path and put main.go on main directory.
• https://github.com/iawia002/annie put main.go on the module path.

I was wondering if putting go file on the module path is a good practice.

Answer 1

This is largely opinion-based. Putting main.go into the repository root is often seen with small programs that don't have a lot going on. When the main package starts getting a lot of files, what some do is to put tightly coupled code into a subfolder called cmd and code that can in theory be reused by other projects into a subfolder called pkg . At that point though, the code in pkg might as well have its own repository.

Putting the main package into a subfolder, while still having another package in the repository root, can have various reasons:

• It could be just example code.
• It could be that the root folder package serves to call a binary built from main in a specific manner; ie a hierarchical folder/package structure where code that tends to get called later during project execution is placed further down the folder tree.
• It somehow historically evolved that way, and is not in need of an urgent change.
• Literally any idiosyncrasy you can or can not think of.

As a rule of thumb though, it is a good idea to name things so that people don't have to specify an import alias to import a package. Eg don't put a package foo in a folder called bar . Naming a module in a manner that one can copy into a browser's address bar to get right to it's repository overview is also a practice I have seen being welcome among people.

Package import paths in Go have many similarities to what's known as namespaces in other languages. Over time, for better or worse, developers and languages alike have begun using this mechanism for more than just avoiding lexical name collisions. Developers will often attempt to achieve a logical, hierarchical folder structure within which code is placed. Languages extensively use it to limit visibility of methods and fields. As you might guess, what lies ahead is a heated opinion-based discussion unsuited for Stackoverflow.