<p>Hello,
I have a little go project where client and server are split in their own packages.</p>
<p>Both of these have the same type</p>
<pre><code>type Data struct {
...
}
</code></pre>
<p>for communication (json).</p>
<p>Now my question is: Is it better to define this struct in both (client, server and maybe more) packages or make an extra package to include the definition from there?</p>
<p>My thinking is when there is a change I only have to change it once, instead of many times and just save lines of code.</p>
<p>Thanks for your advice.</p>
<hr/>**评论：**<br/><br/>jerf: <pre><p>It's better to share the same structure type, usually. It retains flexibility to rearrange things later. If you separate them now, they'll inevitably diverge, and there is decent chance that will be inconvenient later.</p>
<p>Bear struct embedding in mind, too. You can factor common portions of structs out in Go in a way most languages don't do as well.</p></pre>ston1th: <pre><p>So in this case the best way would be to share the struct using a package lets call it for example <code>package structs</code> to define the structs I want to share and import this package into the other ones?</p></pre>bluexavi: <pre><p>Or possibly to make the client dependent on the server (which makes sense in at least some contexts.)</p></pre>ejayben: <pre><p>i put data structs into a shared package and put each "package main" script in its own directory under a cmd folder (aka cmd/client/main.go and cmd/server/main.go)</p></pre>jerf: <pre><p>I want to add that ejayben's solution is probably current accepted best practice.</p>
<p>Generally I'm not a big fan of packages with names like "structs"; I'd really rather see "common" or something else that indicates its function rather than its implementation. But, no sarcasm & fully seriously, your mileage may vary. Part of the reason for that is that over time you're likely to find more code wandering in to that package, and the sort of code that wanders in and belongs there may begin to suggest a better name.</p>
<p>It is certainly common in this sort of situation to still end up with vast swathes of functionality in the "core" package and for the client and the server to just end up thin drivers around those things.</p></pre>010a: <pre><p>I can't speak for best practices, but if you imagine that your packages have to be arranged in a hierarchy such that no cyclic imports exist, then it makes sense that there should exist a package which depends on no other packages in your project. </p>
<p>In some projects I've named this package <code>util</code> and its where I put things like common struct definitions, common error checking, net/http wrappers... basically everything which could be categorized under miscellaneous. Other good names might be <code>common</code> or <code>types</code> if it only contains structs and interface definitions. </p>
<p>Your goal is always to produce readable code. So when you import and use the stuff in this package, which is more clear? <code>structs.Data</code>, <code>util.Data</code>, or <code>types.Data</code>? </p></pre>slrz: <pre><p>Actually, they're all terrible as they don't say anything on what the data is about. If, say, your types represent stuff on reddit, you might call the package reddit and then have types like reddit.User, reddit.Comment, and so on.</p></pre>010a: <pre><p>That's beside the point. I assume <code>data</code> is a stand-in example name for a more specific struct name he didn't want to reveal. </p></pre>ston1th: <pre><p>Thank you all for your advices.</p>
<p>Calling the global package <code>common</code> or <code>util</code> seems to be the best solution, unless it gets too big and parts should get split off into better named packages.</p></pre>peterbourgon: <pre><blockquote>
<p><strong>Bad package names</strong></p>
<p>Packages named <strong>util, common, or misc</strong> provide clients with no sense of what the package contains. This makes it harder for clients to use the package and makes it harder for maintainers to keep the package focused.</p>
</blockquote>
<p><a href="https://blog.golang.org/package-names" rel="nofollow">https://blog.golang.org/package-names</a></p></pre>ston1th: <pre><p>Damn :P</p>
<p>So what is your advice on this?</p></pre>peterbourgon: <pre><p>Your communication isn't just abstract data. It represents something, like bitcoins. Maybe call it package bitcoin. (Or, if I'm wrong, call it <em>data</em>.)</p></pre>
