This is the second day of my participation in the August More text Challenge. For details, see: August More Text Challenge

This article mainly shares the classification and meaning of GO source files, as well as the relevant content of the code package, mainly for the purpose of learning the basic syntax of GO, so as not to be unaware of a lot of content. If you’re not familiar with the GO environment variables, click here

Workspace and GOPATH

A workspace is a directory where the project source files are placed. In general, the project source files need to be stored in the workspace. This is not required for command source files (but is recommended in the workspace). The structure of each workspace looks something like this:

My workspace: / Users/shulv/studySpace/GolangProject SRC/PKG/bin /Copy the code

Official recommendation: Put all projects and third-party libraries in the same GOPATH (of course, you can not do this, you can put each project in a different GOPATH)

SRC directory

Used to store the project source files, in the code package as the organization form. In other words, within the SRC directory, you can have several levels of subdirectories, each of which is essentially a code package (more on this later).

PKG directory

For archive files (files with.a name), all archive files are stored in a platform-specific directory in this directory, also organized as code packages

Platform Related Contents

In the GO environment setup article, GOOS and GOARCH are two environment variables that represent the operating system for which the code is compiled and the architecture or processor for which the code is compiled

The platform directory is named GOOS_GOARCH. If my computer is running a 64-bit MAC OS, the platform directory would be darwin_amd64

All libraries or packages that we have compiled or installed will be installed in the workspace directory/PKG/platform-based directory/level 1 / Level 2 / level 2 / level 3. A

Bin directory

The executable file used to hold the GO program in the current workspace. When we configure the environment variable, we have a GOBIN whose value is the path to the bin directory in the workspace

There are two cases where the bin directory becomes meaningless

  1. When the environment variable GOBIN already sets a valid directory, the directory becomes meaningless
  2. When the GOPATH value contains the paths of multiple workspaces, GOBIN must be set (at this point, the bin directory in each workspace is not really useful), otherwise the GO executable cannot be successfully installed

Source file classification and meaning

GO source file

Go source file, is to. Go as the suffix, the content of the GO language code organization files. Multiple GO source files need to be organized as packages

GO source file classification

Divided into three categories: command source files, library source files, test source files

Command source files and library source files have certain functions, that is, we usually say go source program. The test source file is used to test the above two types of files, it is an auxiliary source file

Command source file

Declare that it belongs to the main code package and contains the main function with no parameter declaration and result declaration. Source files that meet this condition can be classified as command source files. Such as

** import "FMT" func main() {//** contains the main function with no parameter declaration and result declaration ** fmt.println ("Just a test")}Copy the code

After the command source files are installed (how the source files are installed will be shared later in the go common commands), the corresponding executable files will be stored in the directory that GOBIN points to: the current workspace /bin directory (if there is only one workspace, it will be installed in the current workspace bin directory).

The command source file is actually the entry point of the GO program, but it is not recommended to write the program in one file. Note: It is strongly not recommended to include multiple command source files (i.e., go program entries) in the same code package (which can be understood as a directory for the time being). Command source files should be placed in a separate code package. Multiple command source files can be run separately from go run, but cannot be run through go build and go install (common go commands will be shared in a separate article).

Library source file

In fact, it does not have the command source file of the two characteristics of the source file. After the library source files are installed, the corresponding archive files will be stored in the current workspace directory/PKG/platform related directory

Generally used to centrally place various program entities (global constants, global variables, interfaces, structures, functions, and so on) that are ready to be used

Test source files

It is also a source file that does not have the two characteristics of the command source file. The name is suffixed with _test.go

Test source file, must have a test function. There are two kinds of Test functions, one is the Test function prefixed with Test, called function Test function, the other is the function prefixed with Benchmark, called Benchmark function or performance Test function. In addition, they need to accept a parameter of type *testing.T and *testing.B, respectively

Func BenchmarkFind(b *testing.B){} func BenchmarkFind(b *testing.B){}Copy the code

Knowledge of code packages

In the above mentioned several times the code package, the following details to share the code package related content

What the code package does

The basic unit for compiling and archiving GO programs. In other words, we can put several go program source files under a code package, and then compile or archive the code package

Code packages are also an effective form of organization for code division, aggregation, and dependency, and an auxiliary means of permission control. Through the study of the following knowledge of GO language, I will have a deep understanding of this paragraph

Code package rules

A code package is actually a directory represented by the import path

The import path is actually a subpath that can exist in either the workspace directory/SRC or the workspace directory/PKG/platform related directory

Such as: Code package study. Cn, can correspond to/Users/shulv studySpace GolangProject/SRC/study. Cn directory (among them, / Users/shulv/studySpace/GolangProject is my workspace)Copy the code

I am to have such a code package, its import path is study. Cn, it corresponds to the file system directory is/Users/shulv/studySpace GolangProject/SRC/study. Cn, We know/Users/shulv/studySpace/GolangProject is one of my workspace, that on the basis of the above rules, study. Cn this code package, Can correspond to/Users/shulv/studySpace/GolangProject/SRC/study. Cn directory. Of course, the study.cn code package can also exist in the corresponding directory, you can replace the previous workspace directory

Declaration of a code package

Each source file must declare the code package to which it belongs. All source files in the same code package should declare the same code package

The difference between package declaration and package import path

The package name in the package declaration statement should be the rightmost subpath of the import path of the package. Such as:

For example, if there is a code package study.cn/learnTool, there is a source file a.go. which belongs to the code package below, then the code package declaration statement inside the source file should be: package learnToolCopy the code

One advantage of this is that if we now want to migrate the learnTool subpackage to another location, we can do so directly without changing the package declaration statement in the source file

Import of code packages

The package name used in the package import statement should be consistent with its import path. Such as:

Let's say I have three packages of code flag FMT strings that I want to import into my current source file, and I need to say import("flag", "FMT", "strings"), and I can see that the import path of the package is exactly the same as the strings in the import statement that I wroteCopy the code

The import method of the code package

  1. An alias import
Import STR "strings" the strings code package to be imported has a name called STR, so in the current source code, when using the strings method, we can write str.hasprefix (" ABC ","a")Copy the code
  1. Localized import
import . "strings"
Copy the code

Let’s say I need to call the HasPrefix() function in the strings code package. I can use HasPrefix(” ABC “,”a”) directly in the source code file.

I found that I can do without prefixes, so this localized import means that we can call the program entities under the strings code package, just like we call the program entities under the current code package, without any prefixes

  1. Just initialize
import _ "strings"
Copy the code

The package is imported into the program source code, but it does not want to call any program entities in the package. It simply executes the initialization functions in the package

Initialization of the code package

The package initialization is provided by the package initialization function, which is an init function with no argument declaration and no result declaration

The init function can be declared in any file, and there can be more than one

Timing of init function execution — within a single code package

Within a single package, when importing a package, the package’s global variables are evaluated first, and after all global variables are evaluated, all init functions in the package are executed. The order of execution of multiple init functions in the same code package is uncertain

Timing of init function execution — between different code packages

If both the current package and the package it imports have init functions, first execute the init function in the imported package, and then execute the init function in the imported package

Suppose you have three code packages, A, B, and C. They are imported in the order that B is imported from A and C is imported from B. In this case, init functions in these three packages are executed in order C, B, and A

We should not make assumptions about the order of execution of init functions for multiple packages that are imported into the same package. For example, if we have three packages a, B, and C, and b and C are imported into package A, we should not assume which package b or C init function is executed first

Timing of the init function — all the code packages involved

In the go program, all the init functions of imported packages are executed before the entry of the program (i.e., main). In other words, init is executed before main. No matter how many init functions there are, each init function is only executed once

How the GO language looks for dependencies when compiling

At compile time, the GO language will go to different GOPATH to find the packages it depends on. Such as:

Let's say I have a study. Go file that introduces import (" FMT ""study.cn/learnGo")Copy the code

The packages FMT and study.cn/learnGo were introduced in study.go. When compiling study.go, it will first go to the SRC directory specified by GOROOT to look for the related dependency package. At this point, it will find the FMT system package, and if there is no other dependency package, it will go back to the GOPATH directory to look for the related dependency package

Thanks for the following excellent articles

Workspaces and GOPATH as well as basic GO command details

Source file classification and meaning