Minor gripe about formatting result

[cormullion]

This is great! Works brilliantly. I have a minor gripe:

This:

function polyintersect(p1::AbstractArray{Point, 1}, p2::AbstractArray{Point, 1};
    closed=true)
    return false
end

gets formatted to:

function polyintersect(
    p1::AbstractArray{Point,1},
    p2::AbstractArray{Point,1};
    closed = false
)
    return temp
end

and it's the orphaned parenthesis that I'd prefer to not be on a line of its own. One reason is that it stops the function from folding properly in Juno. But the real reason is that I don't like it.

Other than that, it's pretty awesome...

[domluna]

Thanks @cormullion!

I could see that being an option at some point, but I'm treading lightly in that regard at the moment. We'd only want a minimal set of options or else things would get out of control.

[StefanKarpinski]

For what it's worth, this is my preferred way of formatting such a function. I realize that's very subjective and some people aren't going to like it, I just happen to be lucky that @domluna has the same taste in code formatting. I think it may also have precedent in the other code formatters that JuliaFormatter is inspired by?

[domluna]

I did it differently at first but then Simon pointed out this way and it looked way better so I changed it.

…

On Tue, Aug 13, 2019 at 6:50 PM Stefan Karpinski ***@***.***> wrote: For what it's worth, this is my preferred way of formatting such a function. I realize that's very subjective and some people aren't going to like it, I just happen to be lucky that @domluna <https://github.com/domluna> has the same taste in code formatting. I think it may also have precedent in the other code formatters that JuliaFormatter is inspired by? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAORUFZMYO5YW73YDRGUETDQEM3EVANCNFSM4IJ5HK4A> .

[cormullion]

de gustubus non est disputandum .... :) If the little orphan was indented I could learn to love it...

[StefanKarpinski]

I do think that this is a pretty defensible formatting as well:

function polyintersect(
        p1::AbstractArray{Point,1},
        p2::AbstractArray{Point,1};
        closed = false
    )
    return temp
end

However, I can't help seeing the arguments as indented from function too far. I've also always liked that arguments with default values look like they're being assigned just like normal assignments at the head of the function, which is actually very close to what's actually happening.

[domluna]

It's also not as consistent with other indentation. i.e. having really long function names or macro uses causes a huge indentation step and then going back to a 2-4 space indent for the body. Visually it seems disconnected.

[cormullion]

Yes, I have no problems with the indentation, just the parenthesis on its own in column 1. My gripe is probably because I used to work in Lisp - where you'd never put a closing parenthesis on a line by itself, but after the contents it encloses. It's not much of a problem - easily fixed with a regex! :)

[Nosferican]

For me, the biggest issue is code folding. The returned ) or ] should be indented to allow for code folding.

[cormullion]

I posted this a few years ago - since then have there been any new options that could solve my gripe?

[penelopeysm]

YASStyle is probably the closest fit:

julia> s = """
       function polyintersect(p1::AbstractArray{Point, 1}, p2::AbstractArray{Point, 1};
           closed=true)
           return false
       end"""
"function polyintersect(p1::AbstractArray{Point, 1}, p2::AbstractArray{Point, 1};\n    closed=true)\n    return false\nend"

julia> format_text(s, YASStyle()) |> println
function polyintersect(p1::AbstractArray{Point,1}, p2::AbstractArray{Point,1};
                       closed=true)
    return false
end

The closing paren always goes with the final argument (unless there's something pathological like a line comment between them) so that's very much Lisp-like.