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

polaris · · 230 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<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="" rel="nofollow"></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="" rel="nofollow"></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="" 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>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

230 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传