Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update style guide to reflect standard Go module layout #1328

Merged
merged 2 commits into from
Jan 9, 2024
Merged

Update style guide to reflect standard Go module layout #1328

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
60fa6da
Update style guide to reflect standard Go module layout
hanzei Jan 9, 2024
96c566c
Merge branch 'master' into standard-go-module-layout
cwarnermm Jan 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 2 additions & 13 deletions site/content/contribute/more-info/server/style-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,20 +22,9 @@ The following guidelines should be applied to both new and existing code. Howeve

### Project layout

When starting with a new application, it's very tempting to declare a bunch of packages and interfaces right off the bat. Avoid that.
When creating a new Go module, please follow the [standardized guidelines](https://go.dev/doc/modules/layout) of the Go team.

It's very hard to know how the project will grow or what the ideal package boundaries are when starting with a project. Don't split your code into `model`, `store`, `app` along with a bunch of interfaces in the first commit itself. Prematurely separating them will lead to an incorrect package API that may be hard to correct later on.

Instead, put everything inside an `internal` package as your starting point. For example, if the name of your project is `mattercool`, the following can be a good first initial structure:

```
|
|- cmd/mattercool
|- internal/server
|- go.mod,go.sum
```

Putting everything under `internal` has the advantage that you're free to change whatever you want without any fallout. After some time, when the project grows, package boundaries will start to appear. At that point, start to separate into sub-packages.
[This blog article](https://go.dev/blog/package-names) provides additional guidance on package names.

Following are some of the anti-patterns to keep in mind:

Expand Down
Loading