<p>Hey <a href="/r/golang">/r/golang</a>,</p>
<p>I've been learning go by myself for a bit now. In university, for every subject we had to do programming in teams of 2-4 people and I learned a lot in this groups, just reading source code from other people. The programs usually weren't that big, so in 30 minutes I could get a firm understanding of most hows and whys. Now since I am learning go by myself, i wanted to take a look at other people's code that maybe is a bit more complex then the usual example code in books.</p>
<p>Do you have any recommendations for that? Like github projects or even certain go libs? Bonus points if the code doesn't solve some very obscure technical problem so it is easy to focus on the language aspects.</p>
<hr/>**评论：**<br/><br/>bupku5: <pre><p>the standard lib! Go's standard lib is nicely done and easy to read</p></pre>achNichtSoWichtig: <pre><p>Ok, I'll start there. Mabe it really is the best to just start looking at code, where I know what it does, but probably not how.</p></pre>Telefonica46: <pre><p>I second the opinion that the standard lib is a great start.</p>
<p>I also personally like <a href="https://github.com/RichardKnop/go-oauth2-server">this oauth2 library</a>. Notice how he separates each bit of his code into "services". Each service has an interface definition detailing the methods the service performs and then a struct which actually performs said service. This makes it very easy to write your own custom service which may need to perform different logic.</p></pre>SeerUD: <pre><p>Not a fan of the oauth2 library to be honest. Names like <code>health.ServiceInterface</code> aren't very idiomatic, and suggest that the interface has been made solely for the sake of there being an interface.</p>
<p>Bear in mind, you can make an interface for the methods you use on a concretion <em>where you use it</em>. That's one of the most powerful aspects of Go's type system. It avoids these naming smells too.</p></pre>Telefonica46: <pre><p>Can you explain your point about "making an interface for the methods on a concretion", please? I don't understand. Thanks!</p></pre>SeerUD: <pre><p>Sure thing. Let's say you're using a struct from a library in some of your own functions / methods, then you can create an interface that only contains the methods that you use on that type, where you use that type: <a href="https://play.golang.org/p/ZkPuJd6Xdm" rel="nofollow">https://play.golang.org/p/ZkPuJd6Xdm</a> (More <a href="https://github.com/golang/go/wiki/CodeReviewComments#interfaces" rel="nofollow">info here</a>)</p>
<p>Despite what it does say in that link above, this can be useful can whilst testing, because if you only use a couple of methods from something that actually has say 10 methods, you can make an interface with those couple of methods instead, allowing you to mock those 2 methods for a test instead of 10. These kinds of interfaces can be trickier to name though, because they aren't full implementations of the type you're trying to mock.</p>
<p>Sometimes, this isn't always possible though. Some libraries will expect you to pass around an interface they give you because they want you to be able to implement some functionality that plugs into their library. In which case, if they give you both an interface <em>and</em> a concretion for that interface, then there must be some purpose for that concretion's existence (i.e. the interface should be <em>a thing</em>, then the type should be <em>a specialised thing</em>), or alternatively; the concretion should not be exported, and the interface should be all that is exported, and any constructors for it should return that interface as the type (<a href="https://golang.org/doc/effective_go.html#generality" rel="nofollow">see here</a>). This still leaves you able to implement custom versions of that interface, without giving you naming headaches.</p></pre>deferror: <pre><p>This blog post maybe help: <a href="https://www.somethingsimilar.com/2013/12/26/code-to-read-when-learning-go/" rel="nofollow">Code to Read When Learning Go</a></p></pre>achNichtSoWichtig: <pre><p>This is perfect. Thank you! </p></pre>dabshores: <pre><p>The standard library is excellent. To read it sanely, use golang.org/pkg and click functions to jump to the source. You can also use godoc.org/github.com/pkg/sftp etc.</p></pre>sh41: <pre><p>You can also use gotools.org to view the entire package on one page, with Jump To Identifier functionality. E.g., <a href="https://gotools.org/encoding/json#Decoder.Decode" rel="nofollow">https://gotools.org/encoding/json#Decoder.Decode</a>.</p></pre>hell_0n_wheel: <pre><p>If you read a lot of Go, you get good at reading Go.</p>
<p>If you write a lot of Go, you'll bet better at writing Go.</p>
<p>There's a lot more to software than reading or writing a language. Looking at larger projects, you can also learn about organizing code, managing responsibilities, abstracting data sources, using algorithms, etc. You sure it's just golang you're looking at?</p></pre>achNichtSoWichtig: <pre><blockquote>
<p>If you read a lot of Go, you get good at reading Go.</p>
<p>If you write a lot of Go, you'll bet better at writing Go.</p>
</blockquote>
<p>Kind of true, but not the whole picture imho: When you are coding you naturally develop certain patterns to do certain things. Over time, you stop thinking about these patterns because you get used to them become like muscel memory. But maybe there are other, smarter ways of doing things you may never have thought of, which you'll have to discover in other ways then just writing more of the same style of cid. This connection is missing in your statements.</p></pre>hell_0n_wheel: <pre><blockquote>
<p>When you are coding you naturally develop certain patterns...</p>
</blockquote>
<p>Process? Design patterns? Architecture? There are names for these concepts, all of which are orthogonal to the language in which one programs. There's no need to connect the language to the concept, unless that's the only way one can learn...</p></pre>achNichtSoWichtig: <pre><p>I understand what you are saying and maybe you are a genius whose is able to find the correct abstractions and analysis right away. If you look at context driven development, even this to you universally true concepts are debated. I don't always (or probably most of the time) get the abstractions right and may accidently apply antipatterns. Maybe I am no good programmer, but I am pretty sure it is a pointless discussion. I've learned tons for my own coding style by reading code, if you can figure this out by yourself, good job. </p></pre>carsncode: <pre><p>I think it's a mistake to disregard the benefit of reading quality code for learning to write quality code. Just as great writers of prose tend to be great readers, we learn not only by doing, but by example - this is why examples are such a huge part of any programming tutorial, API documentation, or other learning resource. Writing Go code in a vacuum, without reading others' code, will not get you the kind of well-rounded exposure you need to be highly effective, nor will it help you to learn Go idioms and best practices.</p>
<p>It's important to <em>both read and write</em> code to learn well.</p></pre>
