Preferred wrapping for long function declarations
David Cheney
david.cheney at canonical.com
Tue May 13 05:51:07 UTC 2014
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
>
More information about the Juju-dev
mailing list