<p>Hey Gophers,</p>
<p>I am new to go, coding small tools for own use. Is there any best practice guide where I can look and understand how I can organize my code? As golang is not inheritance-style OOP I am having a hard time to wrap my head around to differentiate different modules.</p>
<p>Any suggestion would be welcome!
Thanks in advance.</p>
<p>Edit: Clarification of the question.</p>
<hr/>**评论：**<br/><br/>SportingSnow21: <pre><p>First off, Go is OOP. What it's not is inheritance-style OOP. Structs and Interfaces encapsulate the entirety of OOP.</p>
<p>Organization is generally by functionality. A package is a piece of functionality, with the file contents completely dependent upon dev preference.</p></pre>thepciet: <pre><p>OOP is a way to organize data and algorithms that work on that data. All programming languages are OOP if you still call it OOP after removing the idea of inheritance and classes.</p>
<p>"Object Oriented Programming" is thinking of data and algorithms packaged together in classes (an object's "type" is it's class), which was never accurate to the reality, even if it was a strong stepping stone towards clear features to organize programming with what all computers are: data, and a set of computers instructed by data.</p>
<p>Go programs are just types (data), functions (algorithms), and interfaces (glue?), like it has always been.</p></pre>SportingSnow21: <pre><p>So, a class with data and associated methods is OOP, but a struct with data and associated methods is not? All because one could possibly use inheritance?</p>
<p>Yes, OOP-style programming can be done in C, but it's not a feature of the language. Go allows methods to be declared on a specific type, just like Java, C++, Python, etc. That's the basis of OOP. </p>
<p>The inheritance vs composition and duck-typing distinction doesn't change that. Either way, interfaces are a just a subset of functionality that are defined on an object.</p></pre>thepciet: <pre><p>Code is all template for how memory is organized and what instructions execute on the processor. The value of a programming language is in the human writing of complex systems - computers just want the instructions. An object is a piece of living memory, code defines the layout and interactions of that object.</p>
<p>Go does have methods, but my understanding is that they are just an annotation for regular functions to make code more readable (x.Do() is the same as Do(x) internally). Plus enabling interfaces.</p>
<p>I think we are just discussing terminology. Which is why I made statements about OOP, abstract terminology can add noise anywhere, and the OOP community has lots of abstract terminology. So, yes, I agree, Go is an OOP language, but this is a reduction to patterns that can be implemented in all languages, including assembly. </p>
<p>I associate "Object Oriented Programming" with C++, Java, (haven't hung out with Python folks much yet) and the specific terminology, history, and features of those languages. Go is narrowed to avoid many of the pitfalls those languages experienced - in my mind, part of that is removal of unnecessary abstractions.</p></pre>SportingSnow21: <pre><blockquote>
<p>Go does have methods, but my understanding is that they are just an annotation for regular functions to make code more readable (x.Do() is the same as Do(x) internally). Plus enabling interfaces. </p>
</blockquote>
<p>This is true of C++ and Java, it's just hidden behind the compiler as the keyword "this". Python requires that class methods have the "this" keyword as the first parameter, in order to have a reference to the calling object. The entire attached method construct was originally built around such a setup, Go does the same pattern while adding the ability to name the calling object whatever you want. </p>
<blockquote>
<p>Go is narrowed to avoid many of the pitfalls those languages experienced - in my mind, part of that is removal of unnecessary abstractions. </p>
</blockquote>
<p>From my understanding, the goal was to strip out all the excess from previous OO-languages. We all got a little carried away with adding abstractions to C++ and Java in the real heyday of inheritance-style OOP, hoping to solve every problem via abstraction. I enjoyed a lot of it, but the languages started bloating really quickly. My first language was C++98, which makes C++14 look incredibly verbose (C++ community is really focused on getting some of the complexity deprecated and removed, now). </p>
<p>Also, I've seen some Java devs talking about removing some inheritance from their code and using Go-style composition in its place. I haven't seen that code, but they've seemed to enjoy it. Who knows, it could become a solid design pattern for another community. In the end, a good programming language helps us to think of a program in a little different light. Go-style OOP did that to me and I've enjoyed every minute of it.</p></pre>bbrazil: <pre><p>If you're familiar with Java, Go modules are a mix of Java packages and Maven modules.</p>
<p>The two differences are that:</p>
<ol>
<li>You only have Package and Public visibility</li>
<li>No circular dependencies between Go modules<sup>*</sup></li>
</ol>
<p>Code that is closely tied together should be one module, similarly to what you're put in a Java package.</p>
<p>Go has support for internal modules, these are accessible within one directory and it's descendants (e.g. github repository) but not outside it. These are useful as otherwise anyone would be able to access your public functions.</p>
<p><sup>* Maven enforces this between modules in your pom.xml, but there's nothing in Java to enforce it between packages</sup></p></pre>skarlso: <pre><p>Hi. </p>
<p>This might help you. </p>
<p><a href="http://blog.sgmansfield.com/2016/01/an-analysis-of-the-top-1000-go-repositories/" rel="nofollow">http://blog.sgmansfield.com/2016/01/an-analysis-of-the-top-1000-go-repositories/</a></p>
<p>It's a blog post about analysing a 1000 large go repositories and how they are structured. Might shed a light on how the big ones do it. </p></pre>Depado: <pre><p>There are some kind of best practices. For exemple you can analyze your code with Gocyclo which will tell you if a function is too long or too complex. Meaning you need to split it. Smaller functions are easier to test. Don't hesitate to create small packages even if they contain only a few lines of code, there is nothing bad about this. </p>
<p>Also make sure you only make public what you need outside of your package (upper-case first letter of the function/variable). </p>
<p>This tool is pretty cool to check for best practices. <a href="http://goreportcard.com/" rel="nofollow">http://goreportcard.com/</a></p></pre>thepciet: <pre><p>I wouldn't worry about organization much until you have a strong practical understanding of Go interfaces and can isolate code that is independent of your specific project application.</p>
<p>Put it all in package main and get going!</p></pre>
