Go Project: Difference between revisions
(→cmd) |
|||
Line 38: | Line 38: | ||
===<tt>cmd</tt>=== | ===<tt>cmd</tt>=== | ||
The directory contains the main applications for this project. If the project has multiple executables, their code should live under their own directory, and the name of the directory should match the name of the executable. The Go code file name can be either <code>main.go</code> | The directory contains the main applications for this project. If the project has multiple executables, their code should live under their own directory, and the name of the directory should match the name of the executable. This convention aligns with the behavior of the <code>go build</code> command, which [[Go_build#Executable_Name|names the executable after the name of its parent directory]]. The Go code file name can be either <code>main.go</code>, which is preferred, or the name of the command <code>myserver.go</code>. Different projects use one of these two conventions. Do not put a lot of code in the <code>/cmd</code> directory. If you think the code can be imported and used in other projects, put it in the <code>[[#pkg|/pkg]]</code> directory. If the code is not reusable, put it in the <code>[[#internal|/internal]]</code> directory. It's common to have a small <code>main</code> function that imports and invokes the code from the <code>/internal</code> and <code>/pkg</code> directories and nothing else. | ||
====<tt>main.go</tt>==== | ====<tt>main.go</tt>==== |
Revision as of 19:46, 14 December 2023
External
Internal
Overview
This page collects recommendation and facts about Go projects and it was mainly written with the assumption that one project lives in its own repository and contains a single module, as described in Packages, Modules, Projects and Repositories. Of course project can contain multiple modules, but that is not recommended.
A Java-style /src
is not recommended.
Project Layout
This layout is inspired by:
. ├── cmd │ ├── myserver │ │ └── main.go │ └── myclient │ └── main.go ├── pkg ├── internal ├── scripts │ ├── build-myserver.sh │ └── build-myclient.sh ├── Makefile ├── README.md ├── go.mod ├── go.sum └── .gitignore
Directories
cmd
The directory contains the main applications for this project. If the project has multiple executables, their code should live under their own directory, and the name of the directory should match the name of the executable. This convention aligns with the behavior of the go build
command, which names the executable after the name of its parent directory. The Go code file name can be either main.go
, which is preferred, or the name of the command myserver.go
. Different projects use one of these two conventions. Do not put a lot of code in the /cmd
directory. If you think the code can be imported and used in other projects, put it in the /pkg
directory. If the code is not reusable, put it in the /internal
directory. It's common to have a small main
function that imports and invokes the code from the /internal
and /pkg
directories and nothing else.
main.go
Some project name this file myserver.go
.
package main
import "fmt"
func main() {
fmt.Print("starting my service ...\n")
}
pkg
internal
scripts
This directory contain scripts to perform various build functions, install, analysis, etc.
They should be used by Makefile
, which will keep the file small and simple.
Files
Makefile
Makefile
should prefer to use scripts from the /scripts
directory, which should keep it simple.
.PHONY: build dwm
build: myserver myclient
myserver:
"$(CURDIR)/scripts/build-myserver.sh"
myserver:
"$(CURDIR)/scripts/build-myclient.sh"
Example to process: https://github.com/hashicorp/terraform/blob/main/Makefile
Microservice-based Project Layout
TODO
Integrate Vendoring.