When you're first getting started and mostly playing around, there's no real problem with setting your application lazily.
For example, to get started as quickly as possible, you can create a simple hello.go file anywhere you like and compile without issue.
But when you get into environments that require multiple or distinct packages (more on that shortly) or have more explicit cross-platform requirements, it makes sense to design your project in a way that will facilitate the use of the go build tool.
The value of setting up your code in this manner lies in the way that the go build tool works. If you have local (to your project) packages, the build tool will look in the src directory first and then your GOPATH. When you're building for other platforms, go build will utilize the local bin folder to organize the binaries.
When building packages that are intended for mass use, you may also find that either starting your application under your GOPATH directory and then symbolically linking it to another directory, or doing the opposite, will allow you to develop without the need to subsequently go get your own code.
As with any language, being a part of the Go community means perpetual consideration of the way others create their code. Particularly if you're going to work in open source repositories, you'll want to generate your code the way that others do, in order to reduce the amount of friction when people get or include your code.
One incredibly helpful piece of tooling that the Go team has included is go fmt. fmt here, of course, means format and that's exactly what this tool does, it automatically formats your code according to the designed conventions.
By enforcing style conventions, the Go team has helped to mitigate one of the most common and pervasive debates that exist among a lot of other languages.
While the language communities tend to drive coding conventions, there are always little idiosyncrasies in the way individuals write programs. Let's use one of the most common examples around—where to put the opening bracket.
Some programmers like it on the same line as the statement:
for (int i = 0; i < 100; i++) {
// do something
}While others prefer it on the subsequent line:
for (int i = 0; i < 100; i++)
{
// do something
}These types of minor differences spark major, near-religious debates. The Gofmt tool helps alleviate this by allowing you to yield to Go's directive.
Now, Go bypasses this obvious source of contention at the compiler, by formatting your code similar to the latter example discussed earlier. The compiler will complain and all you'll get is a fatal error. But the other style choices have some flexibility, which are enforced when you use the tool to format.
Here, for example, is a piece of code in Go before go fmt:
func Double(n int) int {
if (n == 0) {
return 0
} else {
return n * 2
}
}Arbitrary whitespace can be the bane of a team's existence when it comes to sharing and reading code, particularly when every team member is not on the same IDE.
By running go fmt, we clean this up, thereby translating our whitespace according to Go's conventions:
func Double(n int) int {
if n == 0 {
return 0
} else {
return n * 2
}
}Long story short: always run go fmt before shipping or pushing your code.