Twelve Go Best Practices

<p><pre><code> if err == nil { _, err := w.Write([]byte(g.Name)) if err == nil { err := binary.Write(w, binary.LittleEndian, g.Age) if err == nil { return binary.Write(w, binary.LittleEndian, g.FurColor) } return err } return err } </code></pre> Why does anyone have to tell people not to do this? How does it enter anyone&#x27;s mind as a thing to do in the first place? I&#x27;ve been known to go <i>too far</i> to minimize nesting. I get twitchy at the second level. By the third my brain is trying to crawl out my eyes and strangle me, even on code that doesn&#x27;t have a potential exit point at every level.

Odd choice of examples...<p>1. The file I&#x2F;O makes the case for including exceptions in the language. Specifically, adding one-off types to deal with exceptions is a bug, not a feature. There is a good case against exceptions but that ain&#x27;t it.<p>2. On slide 5, it appears to show that you have to use a switch statement on a generic to get polymorphism because the language doesn&#x27;t support overloading. Again, looks more like a bug than a feature.<p>Also, is the &quot;break;&quot; implicit in Go? At first glance, it looks like a coding error.

Interesting that this snippet:<p><pre><code> func (g *Gopher) DumpBinary(w io.Writer) error { err := binary.Write(w, binary.LittleEndian, int32(len(g.Name))) if err != nil { return err } _, err = w.Write([]byte(g.Name)) if err != nil { return err } err = binary.Write(w, binary.LittleEndian, g.Age) if err != nil { return err } return binary.Write(w, binary.LittleEndian, g.FurColor) } </code></pre> could be written like this:<p><pre><code> func (g *Gopher) DumpBinary(w io.Writer) { binary.Write(w, binary.LittleEndian, int32(len(g.Name))) w.Write([]byte(g.Name)) binary.Write(w, binary.LittleEndian, g.Age) binary.Write(w, binary.LittleEndian, g.FurColor) } </code></pre> if the language supported exceptions.

Something that doesn&#x27;t sit right with me is the use of a &quot;channel of bool&quot; when the receiving goroutine doesn&#x27;t actually care whether true or false is sent. It muddies the API to force the sender to choose one of two values when all that&#x27;s really wanted is an amorphous signal.<p>e.g. in <a href="http://talks.golang.org/2013/bestpractices.slide#25" rel="nofollow">http:&#x2F;&#x2F;talks.golang.org&#x2F;2013&#x2F;bestpractices.slide#25</a> , the first case in the select will trip regardless of which value arrives, yet the sender was still made to choose one.

The type cast as part of the switch is really cool, I hadn&#x27;t seen that before.<p><pre><code> switch v := v.(type) { case string: w.Write(int32(len(v))) w.Write([]byte(v)) default: w.err = binary.Write(w.w, binary.LittleEndian, v) } </code></pre> Great way to alter control flow based on the type, without a ton of ugly casts cluttering things up.

Meta comment: does anyone know what software is used to generate these slides? I&#x27;ve seen a few slide decks in the same format and they&#x27;re impossible to use on mobile. I&#x27;d like to fix that

&quot;Deploy one-off utility types for simpler code&quot; can be called a monad or Optional. I wonder if the language developers will add more formal support for that; it looks impossible to add Optional as a library due to lack of user-configurable generics.

Didn&#x27;t read, because mouse scroll wheel doesn&#x27;t work.<p>Honestly, who thinks this stuff is a good idea?

Thirteen: don&#x27;t try to sort, it&#x27;s going to be painful if you do.<p><a href="http://golang.org/pkg/sort/" rel="nofollow">http:&#x2F;&#x2F;golang.org&#x2F;pkg&#x2F;sort&#x2F;</a> (See example 1 -- you have to write that for every concrete slice type you want to sort; it&#x27;s not enough to write it once. And god help you if you also want to sort other collection types.)

He starts dropping errors in &quot;Type switch to handle special cases&quot;

Slide deck is good idea - but does not work with swipe on OS&#x2F;X - a clue to click on the right side would be nice.

UI best practice: Avoid horizontal scrolling.

Holy shit that function adapters example is convoluted. I&#x27;d say fewer than 5% of my programmer coworkers would figure out what&#x27;s going on.<p><pre><code> func init() { http.HandleFunc(&quot;&#x2F;&quot;, errorHandler(betterHandler)) } func errorHandler(f func(http.ResponseWriter, *http.Request) error) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { err := f(w, r) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) log.Printf(&quot;handling %q: %v&quot;, r.RequestURI, err) } } } func betterHandler(w http.ResponseWriter, r *http.Request) error { if err := doThis(); err != nil { return fmt.Errorf(&quot;doing this: %v&quot;, err) } if err := doThat(); err != nil { return fmt.Errorf(&quot;doing that: %v&quot;, err) } return nil }</code></pre>

If #6 is among best practices, I&#x27;m sad. I could take a dynamically-typed language instead.<p><a href="http://talks.golang.org/2013/bestpractices.slide#6" rel="nofollow">http:&#x2F;&#x2F;talks.golang.org&#x2F;2013&#x2F;bestpractices.slide#6</a>