[style-guide] Formatting of argument lists

[Thorium]

In the current OSS projects. there exists a push of Fantomas to force implementing the coding conventions of F#, where as those coding-conventions are not complete, creating a gap which is not minded.

IMHO: The coding conventions should focus on maintainability. The intention of the original developer should come clearly visible from the code. Without any kind of statistical analysis, the computer doesn't see that intention from the source code, thus it should keep its fingers off and not auto-obfuscate the code to meet some artificial convention... anyway...

Many developers use wide-screen monitors to replace multiple monitor configuration.
So the coding conventions should adapt to this current world we live in, where the development-monitors being easily 300 characters in width, but still 50 in height.

Therefore, to try to adopt to the situation, I suggest that:

1. Arrays with data only should be allowed to write without line-breaks. Code-lines that will not be maintained line-by-line should be allowed to be long. Stroustrup lines fsprojects/fantomas#2277

2. Unnecessary breaking of namespaces into separate lines should be avoided. Don't break namespaces unnecessarily fsprojects/fantomas#2279

3. Functions with many parameters should add one tab more before function body Functions with many parameters should add one tab more before function body fsprojects/fantomas#2278

4. Mutation of an object should still be preferred as the only action on that line
   Mutable expressions should be on one line fsprojects/fantomas#2280

[auduchinok]

Unnecessary breaking of namespaces into separate lines should be avoided.

From the syntax tree view it's not possible to distinguish a namespace from a static member or a module member access. How it should probably be formulated is try to maintain line breaks inside expressions with dot access and only split them for parts that don't fit on line with current line length settings.

Mutation of an object should still be preferred as the only action on that line

I'd say the same thing here: we should try to keep the original formatting choice for places where the style guide allows variations like this.

[dsyme]

Decision on (4) is here: #663

[dsyme]

On (2) I agree, ideally we should never break namespaces, I think under any circumstances. However it will be difficult to implement because namespaces are not known to fantomas. I don't know how we could implement except a list of known namespaces. And really, good code should open the namespace.

Overall I think we could say this fits under "bad code formats badly"

[dsyme]

On (3) I'm torn, it's not a simple choice. I'm aware it is a realy problem in practice. There is also a major risk of being inconsistent with functions and methods taking tupled paramters.

The current guidance is here: https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/formatting#formatting-function-and-member-arguments

We must also consider the variaitons.

One indent (4-space) - current style guide

let curried:

let sillyfuncWithParams 
    parameterName1
    ignoredParameterName2 
    ignoredParameterName3 =
    ...

let tupled:

let sillyfuncWithParams 
    (
        parameterName1,
        ignoredParameterName2,
        ignoredParameterName3
    ) =
    ...

let mixed:

let sillyfuncWithParams 
    parameterName0
    (
        parameterName1,
        ignoredParameterName2,
        ignoredParameterName3
    )
    parameterName4 =
    ...

let rec curried:

let rec sillyfuncWithParams 
    parameterName1
    ignoredParameterName2 
    ignoredParameterName3 =
    ...

let rec tupled:

let rec sillyfuncWithParams 
    (
        parameterName1,
        ignoredParameterName2,
        ignoredParameterName3
    ) =
    ...

let private curried:

let private sillyfuncWithParams 
    parameterName1
    ignoredParameterName2 
    ignoredParameterName3 =
    ...

let private tupled:

let private sillyfuncWithParams 
    (
        parameterName1,
        ignoredParameterName2,
        ignoredParameterName3
    ) =
    ...

static member curried:

type C() =
    static member sillyfuncWithParams 
        parameterName1
        ignoredParameterName2 
        ignoredParameterName3 =
    ...

static member tupled:

type C() =
    static member sillyfuncWithParams 
        (
            parameterName1,
            ignoredParameterName2,
            ignoredParameterName3
        ) =
    ...

Two indent (8-space)

let curried:

let sillyfuncWithParams 
        parameterName1
        ignoredParameterName2 
        ignoredParameterName3 =
    ...

let tupled:

let sillyfuncWithParams 
        (
            parameterName1,
            ignoredParameterName2, 
            ignoredParameterName3
        ) =
    ...

let mixed:

let sillyfuncWithParams 
        parameterName0
        (
            parameterName1,
            ignoredParameterName2, 
            ignoredParameterName3
        )
        parameterName4 =
    ...

let rec curried

let rec sillyfuncWithParams 
        parameterName1
        ignoredParameterName2 
        ignoredParameterName3 =
    ...

let rec tupled

let rec sillyfuncWithParams 
        (
            parameterName1,
            ignoredParameterName2,
            ignoredParameterName3
        ) =
    ...

let private curried

let private sillyfuncWithParams 
        parameterName1
        ignoredParameterName2 
        ignoredParameterName3 =
    ...

let private tupled

let private sillyfuncWithParams 
        (
            parameterName1,
            ignoredParameterName2,
            ignoredParameterName3
        ) =
    ...

static member curried:

type C() =
    static member sillyfuncWithParams 
            parameterName1
            ignoredParameterName2 
            ignoredParameterName3 =
    ...

static member tupled:

type C() =
    static member sillyfuncWithParams
           ( 
                parameterName1,
                ignoredParameterName2,
                ignoredParameterName3
            ) =
    ...

[auduchinok]

@dsyme We've been using that double-indent approach in ReSharper.FSharp and I haven't seen cases where it wouldn't work well. It always makes it very clear where a function/method/type body begins.

[dsyme]

@auduchinok I've added tupled and mixed cases to the above. What do you think for static members? And is there any reason that case would be different?

[dsyme]

@auduchinok basically it seems it is only curried let that's a problem for single-indentation, because of the unfortuanate exact alignment between function name and curried arguments. But of course it's the most common case as well.

The question is would we use double-indentation for all of the above? Or just the let cases? Or let the single plain let? and would we use double indentation for tupled argument lists? And mixed?

[dsyme]

I've repurposed this issue to be specifically about formatting of argument lists

[auduchinok]

@auduchinok I've added tupled and mixed cases to the above. What do you think for static members? And is there any reason that case would be different?

It could be something like that (i.e. follow the expression rules and keep the opening paren on the previous line):

type C() =
    static member sillyfuncWithParams( 
            parameterName1,
            ignoredParameterName2,
            ignoredParameterName3) =
        ...

In our project I'd format it like this:

type C() =
    static member sillyfuncWithParams(parameterName1, ignoredParameterName2,
            ignoredParameterName3) =
        ...

or (to add a constructor example)

type C(parameterName1, ignoredParameterName2,
        ignoredParameterName3) =
    static member sillyfuncWithParams(parameterName1, ignoredParameterName2,
            ignoredParameterName3) =
        ...

[dsyme]

It's interesting to note that currently this mixed example:

let sillyfuncWithParams
    parameterName0
    (parameterName1,
     ignoredParameterName2,
     ignoredParameterName3,
     ignoredParameterName4,
     ignoredParameterName5,
     ignoredParameterName6)
    =
    1

formats the tuple portion differently to

let sillyfuncWithParams
    (
        parameterName1,
        ignoredParameterName2,
        ignoredParameterName3,
        ignoredParameterName4,
        ignoredParameterName5,
        ignoredParameterName6
    ) =
    1

@nojaf what's the currently implemented rule here? Is treating things taking one tuple of arguments as special?

[nojaf]

@dsyme I believe the mixed example never came up in the style guide before.
We only seem to add the indentation when there is a single tuple parameter.