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 <[email protected]> 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 <[email protected]>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 <[email protected] >> > <mailto:[email protected]>> 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" >> > <[email protected] <mailto:[email protected]>> >> > 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 >> > <[email protected] <mailto:[email protected] >> >> >> > 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 >> > <[email protected] <mailto:[email protected]>> >> 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 >> > > [email protected] <mailto: >> [email protected]> >> > > Modify settings or unsubscribe at: >> > > https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > >> > >> > -- >> > Juju-dev mailing list >> > [email protected] <mailto:[email protected] >> > >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > >> > >> > >> > -- >> > Juju-dev mailing list >> > [email protected] <mailto:[email protected]> >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > >> > >> > >> > >> >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > -- ** Frank Mueller <[email protected]> ** Software Engineer - Juju Development ** Canonical
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
