The following are the 15 best practices that should be followed in Go
Write Go like Go. Don’t try to write it like some other language. It’s not Java, it’s not Python, it’s not Ruby. It’s Go. That means use small interfaces. Return an error if something can fail. Make your code simple, not clever. Be merciless in your push for simplicity.
One good way to learn best practices is to read existing source codes and try to reflect them on your projects
Write small things that compose well, document what you export, don’t be clever. Code for today, don’t guess the future. Write tests for confidence and take out time to refactor. Learn what idiomatic Go looks like. The best way is to read standard Go code.
The number one thing to understand is that Go is a new programming language. Try and avoid writing code like you would in your current language of choice.
When any developer learns a new design pattern or language feature, the tendency is to use it wherever possible. Go’s certainly no different, and it comes with lots of new tricks. I’d encourage new Gophers to remember that they’re still just programming, and that many times the same tried-and-true patterns are best even in Go. Sometimes a sync.Mutex is better than a channel. Sometimes it’s not worth the extra goroutine. The standard library is full of examples of these and other choices made well.
Interfaces and composition. That is the real magic sauce in Go. Once you really understand those two concepts inside and out, you will begin to write some amazingly readable code.
Avoid over-engineering, and rather than having huge monolithic code bases, make simple pieces that play well together.
Keep functions small, don’t go overboard with long variable names, and avoid creating garbage.
Run gofmt on your code to automatically fix the majority of mechanical style issues. Almost all Go coders in the world uses gofmt.
Do not discard errors using _ variables. If a function returns an error, check to make sure whether the function succeeded or not. Better, Handle the error and return it or that will rise as a panic error when any exceptional situation occurs.
suppose if you want use structures in controllers, as well as models, Create one common file and there you can create the structures.
Variable names in Go should be short rather than long. This is especially true for local variables with limited scope.
Type Switch To Handle Special Cases: Suppose if you’re not sure about what the interface{} type could be, you can use a type switch:
Type Switch With The Short Variable Declaration
Important Code Needs To Be Served First
Import Dot: The import . form can be used to test the circular dependencies. And, it cannot be made part of the package being tested
Document Your Code
Comment Sentences: Comments documenting declarations should be full sentences, even if that seems a little redundant. This approach makes them to format well when extracted into godoc documentation.