How do you or your team format long function / method signatures?

<p>I&#39;ve been implementing some types that perform IO (e.g. database queries, API calls, etc.), and as a result have been passing around things like a context. Along with a receiver, the function name, and a context, it doesn&#39;t leave you with much space left to fit in the rest of your parameters and/or return type on a line.</p> <p>I try to stick to below 100 characters on a single line, because a lot of the time I work with 2 code editors sat side-by-side.</p> <p>For longer function / method signatures, do you chop down your parameters? Or do you just leave it all on one line? Or do you do something else maybe? (I mean, if you cannot possibly make the names of things shorter too).</p> <pre><code>func (s *SomethingLong) WithAReasonableName(ctx context.Context, param1 string, param2, param3 int) (WithAReasonableName, error) { // ... } func (s *SomethingLong) WithAReasonableName( ctx context.Context, param1 string, param2 int, param3 int, ) (WithAReasonableName, error) { // ... } </code></pre> <p>That second approach is a lot easier to fit in, but sometimes I wonder if it&#39;s harder to read? Also, it&#39;s a bit more difficult to do that in an interface declaration too...</p> <hr/>**评论：**<br/><br/>kerakk19: <pre><p>You can always use some struct type with your fields, so it&#39;ll accept only this struct. But if you want to do it, remember to never put context inside struct(as a field).</p> <p>So it would be something like this:</p> <pre><code>type YourStruct struct { param1 string param2 int param3 int } func (sl *SomethingLong) WithAReasonableName(ctx context.Context, ys YourStruct){ ... } </code></pre></pre>kpurdon: <pre><p>+1 on this, <a href="https://godoc.org/github.com/aws/aws-sdk-go/service/s3" rel="nofollow">https://godoc.org/github.com/aws/aws-sdk-go/service/s3</a> (and others libs in that package) use this pattern a lot and I really enjoy it.</p></pre>SeerUD: <pre><p>That&#39;s not a bad idea!</p></pre>Parceira: <pre><p>Could you give some examples of what you mean by “context”?</p> <p>(OP and commenters)</p></pre>kerakk19: <pre><p><a href="https://golang.org/pkg/context/" rel="nofollow">https://golang.org/pkg/context/</a></p></pre>TheMerovius: <pre><p>I just leave the line long and rely on the soft-wrapping of my editor. Of course, if it gets too much, I&#39;ll try to find a way to refactor it or choose better names; but less because it&#39;s too long a line and more because a <em>much</em> too long line indicates that the naming/signature was probably chosen poorly.</p></pre>arp242: <pre><blockquote> <p>I just leave the line long and rely on the soft-wrapping of my editor</p> </blockquote> <p>One downside of this approach is that you have horizontal scrollbars in godoc, which is bad UX IMHO.</p> <p>Not always an issue, but something to be aware of, especially when you&#39;re writing public libraries.</p></pre>TheMerovius: <pre><p>IMO that has the same severity as having too long a line in general; it&#39;s not like it&#39;s <em>great</em> if my editor has to soft-wrap. From this POV, I consider this caught by the second half of my answer :)</p></pre>Sythe2o0: <pre><p>I use <a href="https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis" rel="nofollow">variadic functional options</a>.</p></pre>SeerUD: <pre><p>I take advantage of that where possible, but it&#39;s not always possible, or the right choice. I stick to using them when I need 0 or more of some specific thing, and not some distinct things.</p></pre>Parceira: <pre><p>Thanks for the link.</p> <p>As usual Dave Cheney illuminates, and makes me want to rewrite chunks of my code. </p></pre>