So what about this 'cmd' folder?
The post has already made it clear, to summarise:
- It's not a magic nor standard in Go. It's just a convention.
- You can have multiple binaries when putting them into a sub-folder which is not possible in the root folder.
- By making you taking your binary as a client instead of a host or portal of your application, it can drives you to the so-called 'library-driven-development' way of architecting your program. This separation 'helps you make a cleaner abstraction' and more common of you code logic.
And what is the best practice for structuring project files in Go that support source files, projects binaries, 3rd party packages and unit tests.
I'm not sure about the best practice. The official documents have many hints about the project files structuring. On my personal practice, besides the cmd
folder for the binaries, I
- Group source files into packages(sub-folders) inside the
src
folder,
- Copy 3rd party packages to the vendor folder;
- Place unit tests files side by side with its target source file.
These links may be helpful:
Organizing Go code
The Go Blog: Organizing Go code
The Go Blog: Package names
golang-standards/project-layout (*)
As @DiegoMendes pointed out, there are controversy about proposals in the last link. You should also check the issue 117 of that repo which contains a lot of valuable information.