Function signature formatting
cypressious opened this issue · 8 comments
If the function signature doesn't fit on a single line, I propose the following syntax, similar to the class header syntax proposed by me in #2:
fun longMethodName(
argument: ArgumentType = defaultValue,
argument2: AnotherArgumentType
): ReturnType {
// body
}Fixed it
Since a class primary constructor declaration has a lot in common with a function declaration, I believe the style for a muti-line function header must be the same as for a multi-line class header at #2
How does this relate to #1? Should expression bodies be permitted for long function signatures?
I'm not a big fan of the idea of requiring wrapping before the closing parenthesis of a long parameter list, or after the opening one. It's important that parameters should be aligned vertically, but I'd allow more flexibility in how exactly the parameter list is laid out, depending on the lengths of the identifiers involved.
Notice how the topic starter's example is using 4 spaces for continuation indent. Currently, auto-format will "fix it" to 8 spaces. I'd prefer to see 4 space there a written.
@yole If you don't wrap after the open paren you end up with:
fun longMethodName(argument: ArgumentType = defaultValue,
argument2: AnotherArgumentType
so parameters after the first are vertically aligned with the character after the open paren. If anything happens that changes the position of that open paren (eg: renaming the method or changing its visibility) the entire parameter list needs to be realigned. Like you said in #23:
The problem with any kind of vertical alignment is that, while it's easy to implement in a batch code formatting tool, it's much more difficult to maintain during regular code editing, both when you initially type a declaration and when you change something.
Doesn't that imply that mutli-line parameter lists should wrap after the open paren so that they can use a standard amount of indent rather than being vertically aligned with the first parameter?