golint stutter for buffer.BufferAt

<p>I&#39;ve started using golint to help clean up my packages. I&#39;ve got an interface called buffer.BufferAt which golint suggests changing to buffer.At. I don&#39;t think anyone is using this repo yet, but it&#39;s got some attention over the weekend. Does it make sense to make this change?</p> <p><a href="http://godoc.org/github.com/djherbis/buffer#BufferAt" rel="nofollow">http://godoc.org/github.com/djherbis/buffer#BufferAt</a></p> <hr/>**评论：**<br/><br/>mdwhatcott: <pre><p>Tools that help enforce a convention (like golint) can be very helpful a great deal of the time. Such tools also lack the context of your mental model of the application and are therefore at a disadvantage some of the time. If &#34;BufferAt&#34; more effectively conveys what&#39;s going on under the covers, or if it aids readability of the surrounding code, or if there&#39;s some other good reason for keeping it that way then who cares what golint says? Do what you think is best. Sometimes brevity hurts more then helps, and repetition isn&#39;t always bad. Just my 2 cents (but be warned, <a href="http://michaelwhatcott.com/go-code-that-stutters/" rel="nofollow">I still use &#34;this&#34; and &#34;self&#34; for receiver names</a>).</p></pre>nathj07: <pre><p>Ok, so I haven&#39;t read your code but perhaps you could remove the stutter and use a word other than At. I have started to try and avoid stutters in code as for me they slow down reading and understanding. </p></pre>djherbis: <pre><p>Well I have a Buffer interface, and BufferAt is a Buffer which also is a io.ReaderAt, and io.WriterAt. I do try to avoid stutter, but in this case I think BufferAt is more descriptive. I&#39;m not sure something other than At would be appropriate.</p></pre>AYBABTME: <pre><p><code>BufferAt</code> sounds fine to me, more than just <code>At</code>.</p></pre>djherbis: <pre><p>Thanks, I don&#39;t like go against the tool but At felt a little brief.</p></pre>