jfs.world (103) [Avatar] Offline
I'm currently using the source code over at github how I would your standard source code download. So ie. download, copy the relevant source files somewhere (say the current directory), and then experiment/learn by doing a view/'go run'/modify loop. This causes me to not like the unnecessary nesting (translates into extra typing that I have to do when copying) that I see.

Is it possible to flatten the structure where possible?

Case in point: chapter6.

$ find chapter6 -type f

All of these files could be flattened into the main 'chapter6' directory. If each subdirectory only has 1 file, I'd rather have them under the main `chapter6` directory for easier access. Where each listing necessarily has more than 1 file, then it makes sense to create an actual directory for the listing (eg. chapter5/listing72).

Having said that, I recognize that it could also be that somehow others are not using the source code that way (although I have my doubts). So I'm here to ask: would flattening the source code like I suggest be better for you?
Bill Kennedy (68) [Avatar] Offline
Since each source code file is an example that can be built, I have put each of them into a separate folder. If not, running go build will fail.
jfs.world (103) [Avatar] Offline
Right. My point is that I "copy to current dir, and then edit and run", but if everybody else cds into the directory (which will still involve that extra typing, btw) before editing, or simply just runs from that directory ('go build'? 'go build path/to/file.go'? 'go run path/to/file.go'?) without an edit, that's fine. Just wanted to know what everybody else was doing.

I think the only case where the extra separation is necessary is when folks do a pure 'go build' (ie. just type 'go build' at the command line; not 'go build path/to/file.go'). If they do a 'go run', you can have several files declaring 'package main' without a problem.
pires (4) [Avatar] Offline
I find the code on Github helpful and really easy to fiddle with, i.e. build, run.