Where can I learn about code structure and organization?

<p>I&#39;m writing a webapp as a pet project and I had started writing packages for various tasks and read a post basically telling me I was doing it incorrectly (had one called utility that handled a lot of misc tasks).</p> <p>Are there any good resources on how you should organize a project in golang? Or some good example webapps that aren&#39;t incredibly complex?</p> <hr/>**评论：**<br/><br/>nstratos: <pre><p>Here&#39;s a good selection of resources to help you with organizing a Go project:</p> <ul> <li><a href="https://golang.org/doc/code.html">How to Write Go Code</a></li> <li><a href="https://blog.golang.org/organizing-go-code">Organizing Go code</a> (<a href="https://talks.golang.org/2014/organizeio.slide#1">Talk</a>)</li> <li><a href="http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project">Five suggestions for setting up a Go project</a></li> <li><a href="https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091">Structuring Applications in Go</a></li> <li><a href="https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1">Standard Package Layout</a></li> <li><a href="https://peter.bourgon.org/go-best-practices-2016/#repository-structure">Go best practices, six years in</a> + the older version <a href="https://peter.bourgon.org/go-in-production/">Go: Best Practices for Production Environments</a></li> <li><a href="http://www.alexedwards.net/blog/organising-database-access">Practical Persistence in Go: Organising Database Access</a></li> </ul></pre>guglicap: <pre><p>where do you put code that does calculations on data, assuming you&#39;re following &#34;Standard Package Layout&#34;?</p> <p>like, I&#39;ll have a DataService interface implemented by the mssql package which retrieves and stores data, but if I then want to perform calculations on that data, what would I do?<br/> make a calculations package, which implements a DataCalculations interface? because in this case I&#39;m not sure what the interface would look like. </p> <p>EDIT: typo</p></pre>everdev: <pre><p>I see a lot of new Gophers breaking their apps into folders like you do with Node, Rails, etc. In Go, all files necessary for the app/package to function should be in the same folder. Only create packages for standalone, re-usable code.</p></pre>steffen25: <pre><p>Hey man I was in the same situation as you described when I began with my first Go project an api I couldnt find any good way to structure my app so I did what I’m used to in php (kind of). My structure could probably be done in a smarter way but hey you gotta start somewhere :)</p> <p>You are welcome to check it out at </p> <p><a href="https://github.com/steffen25/golang.zone/" rel="nofollow">https://github.com/steffen25/golang.zone/</a></p> <p>You can also try out the live demo if you would like at <a href="https://golang.zone" rel="nofollow">https://golang.zone</a> a Vuejs front end that is also open source </p></pre>vldo: <pre><p>recently stumbled upon <a href="https://www.youtube.com/watch?v=LHe1Cb_Ud_M" rel="nofollow">ways to do things</a> by <a href="/u/peterbourgon" rel="nofollow">/u/peterbourgon</a> which has a refreshing way of viewing all this</p> <p>also depending on your scope <a href="https://github.com/marcusolsson/goddd" rel="nofollow">go-ddd</a> or <a href="https://gobuffalo.io" rel="nofollow">gobuffalo</a> for rapid web dev which might be a good place to start</p></pre>hell_0n_wheel: <pre><p><a href="https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670" rel="nofollow">This book is oft-cited on Hacker News</a> and is largely devoted to code structure and organization.</p> <p>Structure and organization generally isn&#39;t a language-specific thing. There are practices from the Single Responsibility Principle and rules of thumb like &#34;don&#39;t write a function that can&#39;t fit on one screen&#34; that one should follow when coding in any language...</p></pre>goenning: <pre><p>When I started working on my project, I was greatly influenced by gogs (<a href="https://github.com/gogits/gogs" rel="nofollow">https://github.com/gogits/gogs</a>). As the time goes by, I kinda changed the structure a bit.</p> <p>If you want to have a look, the project is <a href="https://github.com/getfider/fider" rel="nofollow">https://github.com/getfider/fider</a> and I organize it like:</p> <ul> <li>app/actions: The input struct that is mapped from POST requests. Each action knows how to validate itself and check whenever current user can perform that action.</li> <li>app/handlers: One handler per route. They receive a request and return a response.</li> <li>app/middlewares: They wrap common functionality like authorization, open/commit/rollback transaction, logging, fill the context with userfull information for the handlers</li> <li>app/models: Just dummy models that are either used for Input, Output or Internal</li> <li>app/storage: Interfaces and structs to access the storage the models. I currently support only inmemory and postgres. InMemory is used only for unit testing, while postgres package is used when the application is running. In the future I plan to add mysql and mongo by just creating a new package and implement the interfaces.</li> <li>app/pkg/*: common packages that are not used by the storage, handlers, middlewares, actions, etc. I also like to wrap most packages into my own packages (example: web, jwt, oauth, dbx) so that I can expose a simpler API to the handlers and easily exchange an internal package with another one.</li> </ul> <p>Hope it can help you somehow!</p></pre>shovelpost: <pre><p>While it definitely works, it is better to make it a habit to avoid generic package names. Please read <a href="https://dave.cheney.net/2016/08/20/solid-go-design" rel="nofollow">SOLID Go Design</a>.</p></pre>wavy_lines: <pre><p>There&#39;s no right way to structure code. Everyone had their opinion, and any suggestion you read here is merely somebody&#39;s opinion (including this very comment).</p> <p>You should structure your code in a way that makes it easy (effective, efficient) for you to develop the project and navigate it.</p> <p>For example, if putting all the code in one single file makes that easier, then so be it.</p> <p>From my personal experience, the more you break up the code into files and folders, the harder it becomes to navigate and develop it.</p> <p>So my preference is to have a few big files, around 3k lines or so each. Grouped by how often functions call each other.</p></pre>mcandre: <pre><p>One struct per file is a decent place to start for basic project structure. Put application source in cmd/&lt;name&gt;/main.go.</p> <p>Add unit tests alongside library definitions, as &lt;thing&gt;_test.go.</p></pre>wavy_lines: <pre><p>Holy fuck, no please no. One struct per file is fucking insane.</p></pre>