Now that Go undergoes mainstream adoption, you can witness a hunger for more and more convention. The core guidelines are impressive, but obviously they can not cover everything. The following sections address some ongoing attempts on the matter.
All code is pkg if the definition is "library code that's OK to use by external applications”, with the exception for main packages and any code placed in an internal (sub)directory. Using pkg is the same redundancy as using src in a source code repository/directory, or a java directory with .java files.
Yes, there are many projects that don't write APIs in a reusable manner, just like many projects don't follow the compatibility rules from the semantic versioning model. None of it means that we need extra nesting to get it right.
Why should scripts be in a separate directory? Would you relocate the respective routine if it was replaced with a binary for example? Note how Go can be used as a script too (with go run).
Place your scripts in their logical domain instead, just like you would do with any other file. E.g., ./cmd/mytool/mytool.py and ./supplychain/internal/productrange/crawl-vendor1.sh are quite self explanatory just by their name and location alone.
The project-layout “golang-standards” defines a mix without any logic to it. Why is it docs and not tests? Why is it third-party and not tool?
Use singular names in directories. I.e., doc clearly covers the documentation. The amount of documents in doc should not affect the name.
Many enterprise developers simply apply default structures where possible, such as model, dto and util packages. You can not describe anything well with generic names (by definition). Grouping on classification rather than the the actual subject does not bring much benefit, yet somehow this behaviour remains quite sticky. Maybe the naming subject is so complicated that people prefer to avoid in general?