A detailed package structure for the Go language project

Go Language workspaces: typically added to Gopath.

Src

Bin

Pkg

For bin and pkg two directories, the main effect is the Go install/get command, which installs the compiled results into both directories for incremental compilation.

Environment variables are used to implement Gopath just where the tool chain and standard library are stored.

When using version control tools such as Git, it is recommended that you ignore the pkg and bin directories. Create warehouses directly in the SRC directory or directly under the sub-package directory.

Import Package: You must use the Import command, which is the absolute path where the workspace starts with SRC.

In addition to using the default package name, you can use the alias mechanism to avoid conflicts of the same name.

Import imports the path instead of the package name, importing the import method:

1.import "Github.com/test/tester" The default way to import

2.import X "Github.com/test/tester" Alias mode import

3.import. "Github.com/test/tester" Simple way to import (not recommended because it may cause naming conflicts)

4.import _ "Github.com/test/tester" Initialization mode import

The easy way is often used in code testing. Unused packages are imported with an error and can be ignored using initialization.

Some tools support relative paths.

Custom path: Use Go-import jump information on the Web server for the corresponding path name.

Organizational structure:

The package name usually uses the singular form, the source file must use the UTF-8 format, otherwise it will cause compilation error. Use the Go List command to list the package path.

Main Package: Executable entry (entry function: Main.main)

All packages: standard library and all packages found in Gopath

Std/cmd Package: standard Library and tool chain

Documentation Library: Store Document information that cannot be imported (regardless of directory name)

Permissions: All members can be accessed within the package, regardless of whether they are within the same source code, but only the initial capitalization of the name is visible outside the package.

Initialization

Each source file in the package can define one or more initialization functions, but the compiler does not guarantee the order of execution.

In fact, all of these initialization functions (both standard libraries and imported third-party packages) are called by a wrapper function that is automatically generated by the compiler, so it is guaranteed to execute on a single thread and execute only once. The order of execution is related to dependencies, filenames, and order of definition.

There should be no logical association between initialization functions, and it is best to handle only the initialization of the current file. The compiler first ensures that all global variables are initialized before it starts executing the initialization function. If a global variable is referenced in the initialization function, it is best to assign the value directly at the time it is defined.

Because there is no guarantee that the order of execution will be searched again any assignment in the initialization function may have a delay that is invalid.

In the case of code refactoring, we will separate the code and maintain it in the form of a separate package, where the access control based on the initial capitalization is too sketchy, because we want the package export members to be accessible only within a certain scope, rather than being exposed to all users.

The package (including itself) that is stored under the internal directory can only be accessed by packages (with all levels of subdirectories) below the parent directory.

Dependency Management: The introduction of the vendor mechanism, dedicated to the third-party package, to achieve the source package and rely on the full packaging distribution. If internal is for the interior, then vendor is for the outside. Vendor have higher precedence than standard libraries.

Starting from the directory where the source files are located, construct the vendor full path step-by-step until a path match is found. If the match fails, the gopath is still searched. To use the vendor mechanism, you must turn on the "go15vendorexperiment=1" environment variable, which is turned on by default in Go1.6, and you must set the work space for go.

When using go get to download a third-party package, the Gopath first workspace is still used instead of the vendor directory, and there is no real package-dependent management in the current toolchain, but there is a third-party tool implementation.

A detailed package structure for the Go language project