Preferred wrapping for long function declarations

[Nate Finch]

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:

func (c *CustomCaller) MethodCaller(
rootName string,
 version int,
methodName string,
) (rpcreflect.MethodCaller, error) {
}




On Tue, May 13, 2014 at 12:03 PM, Nate Finch <nate.finch at canonical.com>wrote:

> 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.
>
> 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.
>
> 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. ;)
> On May 13, 2014 4:21 AM, "William Reade" <william.reade at canonical.com>
> wrote:
>
>> I personally favour a variant of (3), without necessarily requiring that
>> every param get its own line: ie
>>
>> func (c *CustomCaller) MethodCaller(
>>  rootName string, version int, methodName string,
>> ) (
>> rpcreflect.MethodCaller, error,
>> ) {
>> ...
>> }
>>
>> ...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.
>>
>> 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 :).
>>
>> Cheers
>> William
>>
>>
>> On Tue, May 13, 2014 at 7:51 AM, David Cheney <david.cheney at canonical.com
>> > wrote:
>>
>>> I don't want to have this bikeshed - I vote for people to use their
>>> best judgement and permit anything which fits through gofmt.
>>>
>>> On Tue, May 13, 2014 at 3:37 PM, John Meinel <john at arbash-meinel.com>
>>> wrote:
>>> > In the risk of running a bikeshedding paint-fest, I'm curious what the
>>> > best-recommended practice is for wrapping function declarations that
>>> get a
>>> > bit wide.
>>> >
>>> > Currently I'm writing a function that looks like this:
>>> > func (c *CustomCaller) MethodCaller(rootName string, version int,
>>> methodName
>>> > string) (rpcreflect.MethodCaller, error) {
>>> > }
>>> >
>>> > But the line is about 119 characters, which isn't terrible, but is a
>>> bit
>>> > wide.
>>> >
>>> > Should we:
>>> >
>>> > Not worry about it, you don't usually need to paste into an email and
>>> have
>>> > crummy wrapping anyway, and 80-character terminals are useless. (and
>>> who
>>> > would want to actually look at more than one document side-by-side
>>> anyway)
>>> > Wrap everything to a single indent:
>>> > This can be a slightly shallow:
>>> > func (c *CustomCaller) MethodCaller(
>>> > rootName string,
>>> > version int,
>>> > methodName string) (
>>> > rpcreflect.MethodCaller,
>>> > error) {
>>> > }
>>> > or go all the way with:
>>> >
>>> > func (c *CustomCaller) MethodCaller(
>>> > rootName string,
>>> > version int,
>>> > methodName string,
>>> > ) (
>>> > rpcreflect.MethodCaller,
>>> > error,
>>> > ) {
>>> > }
>>> >
>>> > (note that gofmt forces the )( and ){ to be left aligned).
>>> > Of the two here I probably prefer the latter, because you can at least
>>> > visually distinguish which collection is the parameters and what
>>> grouping is
>>> > the return values.
>>> > args then errors:
>>> > func (c *CustomCaller) MethodCaller(
>>> > rootName string, version int, methodName string) (
>>> > rpcreflect.MethodCaller, error) {
>>> > }
>>> > My particular unhappiness is because the opening character has to be
>>> on the
>>> > previous line so that we don't get the implicit semicolons.
>>> > Fit what you can in ~even lines:
>>> > func (c *CustomCaller) MethodCaller(rootName string, version int,
>>> > methodName string) (rpcreflect.MethodCaller, error) {
>>> > }
>>> > This also the example for  "wrap at 80 characters" because you can't
>>> break
>>> > methodName from string, you have to end the line with punctuation.
>>> > close to 8, break out errors
>>> > func (c *CustomCaller) MethodCaller(rootName string, version int,
>>> methodName
>>> > string) (
>>> > rpcreflect.MethodCaller, error) {
>>> > }
>>> > Note that my email client forces the wrapping on the first line.
>>> > You're doing it wrong, functions with 3 params and 2 return types
>>> should be
>>> > turned into some sort of Params struct instead. (I'd agree if it was
>>> >5 but
>>> > 3 and 2 isn't really very many.)
>>> >
>>> >
>>> > I think our policy is (3), and maybe that's the best of what I've
>>> > encountered.It means that either everything is on one line, or
>>> everything is
>>> > a single value per line, with clear delineation between args and
>>> errors.
>>> >
>>> > Thoughts?
>>> > John
>>> > =:->
>>> >
>>> > --
>>> > Juju-dev mailing list
>>> > Juju-dev at lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>> >
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140513/528e2ec5/attachment-0001.html>