Preferred wrapping for long function declarations
Frank Mueller
frank.mueller at canonical.com
Wed May 14 08:19:24 UTC 2014
Sure, I like the discussion too and it has been interesting to see what
gofmt thankfully else accepts There have been some formats I never tried
before.
mue
On Wed, May 14, 2014 at 9:53 AM, John Meinel <john at arbash-meinel.com> wrote:
> I've personally found it quite edifying to see what William and Nate like,
> and while I don't think we should enforce a One True Way, I have tweaked my
> own preferences a bit from the discussion.
>
> Somewhere between 3 an William's 3. I don't really prefer Nate's 3 because
> the args aren't wrapped the same as the outputs, though I see some merit.
>
> I certainly agree that the only OneTrueWay will be whatever go fmt
> accepts. But it still helps to discuss and see the merits of other people's
> views. Even if we'll never reach consensus we shouldn't fear discussion.
>
> John
> =:->
>
>
> On Wed, May 14, 2014 at 1:38 AM, Tim Penhey <tim.penhey at canonical.com>wrote:
>
>> I'm in general agreement with Dave. I don't think it really matters too
>> much as long as gofmt keeps it sane.
>>
>> As we have already found, everyone will have differing opinions about
>> this, and I'm not going to share mine here.
>>
>> While I understand the desire to get consensus on this topic, we have a
>> team big enough now that I don't think we'll ever get everyone agreeing
>> on a common line wrapping, so I think it will end up being a waste of
>> time trying.
>>
>> gofmt becomes the source of truth. As long as it is happy, I'm happy
>> enough.
>>
>> Tim
>>
>> On 14/05/14 07:55, Nate Finch wrote:
>> > 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
>> > <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:
>> 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 <mailto: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 <mailto: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
>
>
--
** Frank Mueller <frank.mueller at canonical.com>
** Software Engineer - Juju Development
** Canonical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140514/aa86edc8/attachment-0001.html>
More information about the Juju-dev
mailing list