

Organizing Go code - comatose_kid
http://blog.golang.org/2012/08/organizing-go-code.html

======
wonderzombie
This _almost_ feels like it's burying the lede:

    
    
      (The gofmt command has a -r flag that provides a syntax-aware search and replace, making large-scale refactoring easier.)
    

I've been writing Go on some toy projects off and on, and I'm not an expert by
any means, but I had no idea this flag existed. I must've missed when reading
about gofmt. :(

Anyway, it sounds like it could be pretty useful for refactoring.

------
jfaucett
"A good name is the most important part of a software interface" - absolutely
true. Naming is so important and yet so many apis spend seemingly so little
time on this - win32, OpenGL I'm looking at you guys ;

~~~
lwat
"There's only two hard problems in software engineering: Naming things, cache
invalidation and off-by-one errors"

------
james4k
This all makes a lot of sense for non-main packages. I am curious though what
people are doing with their main packages and their non-code dependencies. Say
you were writing a web app in Go, or some other executable. Is the convention
to put main packages in src/cmd/somename? And is there any convention for the
location of related files such as templates, configs, etc.?

What I've been doing recently is keep web apps in separate gopaths, and having
code in src/ like usual (with src/cmd/frontend as an example, then a 'go
install' outputs to bin/frontend), and then relevant dirs to the app: config/,
templates/, etc. all in the root of the gopath, much like a typical project
directory tree I suppose. However, I get the impression this is not the
'right' way to do it.

~~~
enneff
You should put your entire project under $GOPATH/src/path/to/project,
including non-code dependencies and main packages.

~~~
duaneb
This annoys me immensely. I understand a standardized format for installed
packages, but I should be able to dictate the hierarchy of my own code....

~~~
genbattle
If everyone dictated their own hierarchy for their code base, utilities like
go build and go get wouldn't work.

The guidelines are just guidelines - you can still do whatever the hell you
want, but don't expect the standard tools to automatically handle all your own
personal preferences for project structure.

Go had has this structure ever since the Go 1 release - your source goes in
$GOPATH/src/$YOUR_PATH, and the go get/build tool will compile any main
packages to $GOPATH/cmd, and all packages to $GOPATH/pkg/$YOUR_PATH.

If you really want to isolate the code for a specific application/project, why
not use a folder structure like $GOPATH/src/$PROJECT/$PACKAGE or
$GOPATH/src/$PROJECT/$EXECUTABLE. I had problems initially adjusting to the Go
1 workspace changes, but it's really not a big issue once you adapt a little
(like anything in Go).

