<p>TLDR; <a href="https://github.com/stephendolan/zendesk_tools" rel="nofollow">https://github.com/stephendolan/zendesk_tools</a></p>
<p>Hey all,</p>
<p>I've been learning Golang for a few weeks now and have gotten to the point where I feel semi-comfortable writing small utilities with it. What I'd like to get feedback on is a small wrapper for the Zendesk API that uses a config file to email a user a summary of their open issues.</p>
<p>The <a href="https://github.com/stephendolan/zendesk_tools" rel="nofollow">repository</a> is meant to turn into a collection of Zendesk tools (separate Go programs) that will be run in crontabs at different times.</p>
<p>I'd love to get your general feedback on how my Go code reads or any improvements that can be made, but my main concern is whether or not it's acceptable to pack multiple go programs into one "parent" directory. If so, am I doing it correctly here?</p>
<hr/>**评论：**<br/><br/>gohacker: <pre><p>The convention is: no snake_case (use camelCase or CamelCase); imports from the standard library and third-party ones should be separated by an empty line (goimports will format them that way for you):</p>
<pre><code>import (
"log"
"net/http"
"os"
"strconv"
"github.com/aws/aws-sdk-go/aws"
"github.com/aws/aws-sdk-go/aws/session"
"github.com/aws/aws-sdk-go/service/ses"
simplejson "github.com/bitly/go-simplejson"
"github.com/spf13/viper"
)
</code></pre></pre>google_you: <pre><p>What many Go programmers recommend:</p>
<pre><code># $GOPATH/github.com/stephendolan/zendesk_tools
cmd/
cmd1/
cmd1.go
cmd2/
cmd2.go
...
vendor/
github.com/some/thirdparty
file1.go
file2.go
...
</code></pre>
<p>In cmd1.go (and cmd2.go, ...):</p>
<pre><code>package main
import (
"github.com/some/thirdparty"
"github.com/stephendolan/zendesk_tools"
)
</code></pre>
<p>In file1.go:</p>
<pre><code>package zendesk_tools
...
</code></pre>
<p>Benefits of this:</p>
<ul>
<li>go get-able (<code>go get github.com/stephendolan/zendesk_tools/cmd/...</code>)</li>
</ul>
<p>Downsides:</p>
<ul>
<li>godef breaks along with other 3rd party non-GO15VENDORINGEXPERIMENT aware tools (Cannot jump to definition in your editor/IDE).</li>
<li>Ugly import name (github.com/stephendolan/zendesk_tools).</li>
</ul>
<p>What other Go programmers recommend (gb, wgo, ...):</p>
<pre><code># $GOPATH/github.com/stephendolan/zendesk_tools
src/
stephendolan/
zendesk_tools/
file1.go
file2.go
...
cmd/
cmd1/
cmd1.go
cmd2/
cmd2.go
...
vendor/
src/
github.com/some/thirdparty
</code></pre>
<p>In cmd1.go:</p>
<pre><code>package main
import (
"github.com/some/thirdparty"
"stephendolan/zendesk_tools"
)
</code></pre>
<p>In file1.go:</p>
<pre><code>package zendesk_tools
</code></pre>
<p>Benefits:</p>
<ul>
<li>3rd party tools work (<code>GOPATH=${PWD}/vendor:${PWD}</code>)</li>
</ul>
<p>Downsides:</p>
<ul>
<li>Not go get-able (need 3rd party tools to fetch and put into your project workspace so that import would work)</li>
</ul></pre>dankcode: <pre><p>It depends on if you expect others to use this go project. </p>
<p>If the project is meant to be a standalone application (not used as a go module fetched with go get/install)it should have 3 folders labled src pkg & bin in the root. If it is meant to be a library used by other go programs it should have the go source files in the root along with tests.</p>
<p>Take a look at this for guidance:
<a href="https://golang.org/doc/code.html" rel="nofollow">https://golang.org/doc/code.html</a></p></pre>robertmeta: <pre><p>And binaries (bin) and package (pkg) don't live in the GitHub source tree, use releases for that. </p></pre>robvdl: <pre><p>I don't think underscores in method names is very Go-like, we use that in Python but Go prefers names like populateConfigFromFile rather than populate_config_from_file.</p></pre>
