<div dir="ltr">I was twiddling with gofmt, and I stumbled on this format, which is a lot more readable for me, if we want to wrap long lines:<div><br></div><div><div>func (c *CustomCaller) MethodCaller(</div><div><span style="white-space:pre-wrap"> </span>rootName string,</div>
<div><span style="white-space:pre-wrap"> </span>version int,</div><div><span style="white-space:pre-wrap"> </span>methodName string,</div><div>) (rpcreflect.MethodCaller, error) {</div><div>}</div></div><div><br></div><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 12:03 PM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Personally, I find #3 to be very hard to read. It's very difficult for me to look at the signature and find the return values, and it's hard for me to determine where code starts. </p>
<p dir="ltr">My preference is for #1 - let it wrap, and just try to use short names and few arguments so as to avoid it most of the time. The nice thing about letting it wrap is that we're not penalizing the people with big monitors where it won't need to wrap, but the guys with small monitors will still be able to have it wrapped.</p>
<p dir="ltr">I do sort of agree with Dave about gofmt being the one source of truth, and leaving everything else up personal taste, but I think #3 goes to show that personal taste can vary significantly. ;)</p><div class="HOEnZb">
<div class="h5">
<div class="gmail_quote">On May 13, 2014 4:21 AM, "William Reade" <<a href="mailto:william.reade@canonical.com" target="_blank">william.reade@canonical.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I personally favour a variant of (3), without necessarily requiring that every param get its own line: ie<div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">func (c *CustomCaller) MethodCaller(</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px;white-space:pre-wrap"> </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">rootName string, </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">version int, </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">methodName string,</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">) (</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px;white-space:pre-wrap"> </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">rpcreflect.MethodCaller, </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">error,</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">) {</span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px;white-space:pre-wrap"> ...</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">}</span><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">...so that there's clear visual distinction between receiver/method-name, args, and results; but we don't burn vertical space that doesn't support that goal.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div>My personal opinion is that *of course* my preference is obviously correct; but I really have no interest in *mandating* any particular style. I'm +1 on davecheney's "best judgment" approach in general: developers make their code as clean as they can; reviewers flag problems they perceive; both are responsible for quickly and reasonably resolving disagreements. If you can't do that, come and see me and I'll demand that you do what I suggest above :).</div>
<div><br></div><div>Cheers</div><div>William</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 7:51 AM, David Cheney <span dir="ltr"><<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't want to have this bikeshed - I vote for people to use their<br>
best judgement and permit anything which fits through gofmt.<br>
<div><div><br>
On Tue, May 13, 2014 at 3:37 PM, John Meinel <<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>> wrote:<br>
> In the risk of running a bikeshedding paint-fest, I'm curious what the<br>
> best-recommended practice is for wrapping function declarations that get a<br>
> bit wide.<br>
><br>
> Currently I'm writing a function that looks like this:<br>
> func (c *CustomCaller) MethodCaller(rootName string, version int, methodName<br>
> string) (rpcreflect.MethodCaller, error) {<br>
> }<br>
><br>
> But the line is about 119 characters, which isn't terrible, but is a bit<br>
> wide.<br>
><br>
> Should we:<br>
><br>
> Not worry about it, you don't usually need to paste into an email and have<br>
> crummy wrapping anyway, and 80-character terminals are useless. (and who<br>
> would want to actually look at more than one document side-by-side anyway)<br>
> Wrap everything to a single indent:<br>
> This can be a slightly shallow:<br>
> func (c *CustomCaller) MethodCaller(<br>
> rootName string,<br>
> version int,<br>
> methodName string) (<br>
> rpcreflect.MethodCaller,<br>
> error) {<br>
> }<br>
> or go all the way with:<br>
><br>
> func (c *CustomCaller) MethodCaller(<br>
> rootName string,<br>
> version int,<br>
> methodName string,<br>
> ) (<br>
> rpcreflect.MethodCaller,<br>
> error,<br>
> ) {<br>
> }<br>
><br>
> (note that gofmt forces the )( and ){ to be left aligned).<br>
> Of the two here I probably prefer the latter, because you can at least<br>
> visually distinguish which collection is the parameters and what grouping is<br>
> the return values.<br>
> args then errors:<br>
> func (c *CustomCaller) MethodCaller(<br>
> rootName string, version int, methodName string) (<br>
> rpcreflect.MethodCaller, error) {<br>
> }<br>
> My particular unhappiness is because the opening character has to be on the<br>
> previous line so that we don't get the implicit semicolons.<br>
> Fit what you can in ~even lines:<br>
> func (c *CustomCaller) MethodCaller(rootName string, version int,<br>
> methodName string) (rpcreflect.MethodCaller, error) {<br>
> }<br>
> This also the example for "wrap at 80 characters" because you can't break<br>
> methodName from string, you have to end the line with punctuation.<br>
> close to 8, break out errors<br>
> func (c *CustomCaller) MethodCaller(rootName string, version int, methodName<br>
> string) (<br>
> rpcreflect.MethodCaller, error) {<br>
> }<br>
> Note that my email client forces the wrapping on the first line.<br>
> You're doing it wrong, functions with 3 params and 2 return types should be<br>
> turned into some sort of Params struct instead. (I'd agree if it was >5 but<br>
> 3 and 2 isn't really very many.)<br>
><br>
><br>
> I think our policy is (3), and maybe that's the best of what I've<br>
> encountered.It means that either everything is on one line, or everything is<br>
> a single value per line, with clear delineation between args and errors.<br>
><br>
> Thoughts?<br>
> John<br>
> =:-><br>
><br>
</div></div><span><font color="#888888">> --<br>
> Juju-dev mailing list<br>
> <a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
> Modify settings or unsubscribe at:<br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
><br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div><br></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div>