Preferred wrapping for long function declarations
Tim Penhey
tim.penhey at canonical.com
Tue May 13 21:38:57 UTC 2014
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
>
>
>
>
More information about the Juju-dev
mailing list