<p>Effective Go and golint encourage you to avoid "stuttering" by giving names like <code>json.Formatter</code> instead of <code>json.JSONFormatter</code>; for example, most Reader types are just named <code>Reader</code>, "because users see it as <code>bufio.Reader</code>".</p>
<p>I generally like this approach... but it seems to fall apart with struct embedding. Embedded struct names are just the type name without package, and I find it makes it much harder to read initializers (especially). It's almost enough to make me want to entirely avoid the "no stuttering" guideline for types that I embed in other packages in my projects. Any thoughts on this?</p>
<hr/>**评论：**<br/><br/>chownplus: <pre><p>Even within the stdlib there's stuttering, "io/ioutils" being one of the big ones. It's just a guideline.</p></pre>tdewolff: <pre><p>What do you mean with struct embedding?</p>
<p>I've seen instances in the stdlib where there is stuttering because any other name would not make sense. For example, I have a <code>minify</code> package containing a <code>Minifier</code> struct which can <code>Minify(...)</code>. Sometimes it's just that, but can you give an example of your struct naming?</p></pre>Brasilikum: <pre><p>He means something like</p>
<p><code>
struct App{
logrus.Logger
Other Fields
}
app := App{Logger: logrus.New()}
</code></p>
<p>My thought on this is while this does not make it that obvious, I don't see a pragmatic alternative.
I find it good enough that I am warned if I am trying to put in the wrong type. </p></pre>jerf: <pre><p>I have definitely on occasion wished I could both embed and name a field. As near as I can see there's no particular reason that shouldn't be possible. (I'm comfortable with it being a compile-time error if I try to embed two of the same type, which it already is, so no change there.)</p></pre>izuriel: <pre><p>To avoid confusion with this I try to only embed interface types. This way anything conforming to the interface will fit, and if not a simple wrapper around whatever I want that doesn't conform will make it fit the bill and it's done. Then naming of embedded types isn't really a concern.</p></pre>
