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.re...@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.che...@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 <j...@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@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
>> >
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
