Preferred wrapping for long function declarations

[William Reade]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140513/d6687d7e/attachment-0001.html>