Delete this repo

[kostkobv]

Please, delete this repo, because it brings nothing else but confusion and encourages bad practices in go (a lot around naming) especially for beginners.

Especially it's bad when new go developers start to advocate bad practices and use this repo as a reference.

Instead, create a list of resources that would bring knowledge about the "industry standards" (the way how go is written in stdlib)

Like those:

0. Go basics

https://tour.golang.org/welcome/1
https://gobyexample.com/
https://blog.golang.org/context
https://ekocaman.com/go-context-c44d681da2e8

Would highly recommend to read this even if you’re advanced Gopher - http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

1. Style guideline for Go packages

https://rakyll.org/style-packages/

One of the famous figures and main contributors to Go language, Rakyll, writes about importance of naming and structuring of the packages.

2. Effective Go

https://golang.org/doc/effective_go.html

Effective Go article is a community evangel of how effective Go code should be written.

3. Code Review Comments

https://github.com/golang/go/wiki/CodeReviewComments

Wiki page from Go repository with idiomatic code habits that would help you to avoid traps of trying to write Java (or C#, or TypeScript, or Javascript) in Go which never works.

4. Structuring applications for Growth in Go

https://www.youtube.com/watch?v=LMSbsW1Xpwg
In this lightning talk, Ben Johnson gives a quick idea of what kind of issues you might face with inappropriate project structure

5. Best Practices for Industrial Programming

https://www.youtube.com/watch?v=PTE4VJIdHPg
Peter Bourgon dives deeper into the ways of setting up the project structure that are more adopted within the industry, providing also more justifications on an issues that he was facing on his Go journey. A lot of his practices are widely used within the Go community.

[ComaVN]

Thank you for this comprehensive list of resources.

However, nowhere in the list do I see a simple answer to the question: How should I layout my project directories so I don't need to restructure everytime my app grows more complex? If you have specific concerns about the way this example does things, fine, but surely you see value in a standardized project layout that beginners can use without reinventing the wheel?

[dsoprea]

+1

[rof20004]

+1

[kcq]

@kostkobv thank you for sharing your thoughts and references! Some of those references are actually already mentioned at the very beginning of the main README file (e.g., Code Review Comments and Best Practices for Industrial Programming).

Speaking of confusion... I'm a bit confused with your comments about bad practices around naming. The repo itself doesn't have anything about naming Go code or packages. It actually references the official talks and blog posts (e.g., https://talks.golang.org/2014/names.slide , https://golang.org/doc/effective_go.html#names , https://blog.golang.org/package-names ). There are places where non-plural directory names are used and that's mostly based on the official recommendations and rakyll's styling guide, which explicitly states "No plurals").

[thefuga]

Go's stdlib should not be followed. This have been stated by Rob Pike in multiple occasions. As Rob says, not even them knew what was the standard back then. They were not trying to create standards. The effort was to make thinks effective, not to draw standards or good practices.
The examples given in this repository (such as kubernetes) are much closer to a "standard" than Go's stdlib.
Instead of attacking the repo's owner, perhaps you should point where this structure hurts any of the Go best practices (which by the way are generally not followed by the stdlib, as these practices didn't even existed when the stdlib was written).

[taisph]

I've found this repo immensely useful when structuring my own and my team's projects - even our non-go projects adhere to this structure. This issue should just be closed IMO.

[skaldesh]

@taisph I second this, close this issue

[frizbee]

I'm new to Go, really new, and this repo confuses me. When I run go test or go build I'm getting this error

can't load package: package .: no Go files in /home/user/go/src/news-client

When I run go build cmd/news-client I'm getting this:

can't load package: package cmd/news-client is not in GOROOT (/usr/lib/golang/src/cmd/news-client)

When I follow tutorials in Golang, I place main.go in root of my repo, and running go commands without any issue.

I setup go on my machine with instruction from go website. Here is some of my env:

GOPATH="/home/user/go"
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GOMOD="/home/user/go/src/news-client/go.mod"
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user.config/go/env"

My /home/user/go has 3 folders bin pkg src, inside src I created news-client app.

[taisph]

I'm new to Go, really new, and this repo confuses me. When I run go test or go build I'm getting this error

can't load package: package .: no Go files in /home/user/go/src/news-client

When I run go build cmd/news-client I'm getting this:

can't load package: package cmd/news-client is not in GOROOT (/usr/lib/golang/src/cmd/news-client)

Try go test ./cmd/news-client or go build ./cmd/news-client instead.

[frizbee]

Thank you @taisph very simple answer.

for the go test ./cms/news-client it return no test file found: ? news-client/cmd/news-client [no test files] I'm getting the test only when I run go test ./internal/transport/ and only if I cp my env files from root to that directory, otherwise it return error:

ERROR	config/config.go:62	open config.yml: no such file or directory
news-client/internal/config.Setup
	/home/user/go/src/news-client/internal/config/config.go:62

I'm importing config inside test file

  3 import (
  4     "fmt"
  5     "news-client/internal/config"
  6     "testing"
  7 )

I do have another question regarding testing. As I read documentation and followed some tutorials, other developers placing test file next to the tested file;
example:

.
└── sort
    ├── sort.go
    └── sort_test.go

However using current pattern of structure all my tests files should go under ./test directory, which is more understandable to me being Ruby developer.

[crodwell]

@frizbee you need to do something like this:
go test -v ./...

The layout overall isn't too bad, but the /cmd thing should be removed as this makes basic operations a dev would expect to work annoying.

tests should be next to the file named *_test.go . External testing items can reside in /test

[frizbee]

@crodwell thank you

[kcq]

If you don't have/build multiple executables in the same project the /cmd pattern isn't necessary. Having main.go in your root directory should be more than enough.

[jefpmn]

Official or not, standard or not. This is very helpful to make a good start on structuring your go project. Look, i'm using Vue and React. I've handling several project that use either Vue or React. But, all Vue project, is the fastest i can understand than React. What's the secret? they have well written standard. The structure is always predictable and easier to understand, no matter how the code of conduct is. React? everything is different from project to project.

To put it simple, standard is important when you want to work with others. When you start defining your own standard, you alienating future collaborators and even self-sabotage yourself in the future.