Feature: space between function and unit

[nojaf]

This PR splits SpaceBeforeArgument into a more fine-grained set of settings:

      SpaceBeforeUnitArgumentInUppercaseInvocation = false
      SpaceBeforeUnitArgumentInLowercaseInvocation = false
      SpaceBeforeParenthesesInUppercaseInvocation = false
      SpaceBeforeParenthesesInLowercaseInvocation = true
      SpaceBeforeUnitParameterInUppercaseFunctionDefinition = false
      SpaceBeforeUnitParameterInLowercaseFunctionDefinition = false
      SpaceBeforeParenthesesInUppercaseFunctionDefinition = false
      SpaceBeforeParenthesesInLowercaseFunctionDefinition = true
      SpaceBeforeClassConstructor = false

See documentation.

The default settings did not change any unit test behaviour.
For the command line client, I'm forcing the user to use a configuration file.
Something we might want to do for all styling preferences.

Related discussion can be found in #556, #554 and #555.

These new settings allow the code to be formatted the first rule of the G-Research style guide, "Put a space between a function and ()".

Attached the binaries of PR, in case anymore wants to try this out.

space-before.zip

I'm currently not sure all cases are covered, having some doubt regarding class definitions.

Pinging people who might be interested @Smaug123, @saul, @knocte

[knocte]

why use the word "parameter" in some places and the word "argument" in others?

[nojaf]

https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter

[knocte]

interesting 🤔

[knocte]

tbh I still think this explosion of config settings is a bit ludicrous, if I were you I would just have 3: SpaceBeforeFunctionCall, SpaceBeforeFunctionDefinition, SpaceBeforeClassConstructor

[nojaf]

All these settings are necessary because Fantomas now has a weird way of dealing with this.
In order to not break the existing behaviour, this fine-grained configuration is necessary.

Simply said if you format with the current version of Fantomas and later with a version containing this PR you want exactly the same output. Otherwise, this is a breaking change that will upset people.

[knocte]

In order to not break the existing behaviour, this fine-grained configuration is necessary.

I get that, but my 2cents assume this catch. My view on this is: the past behaviour was wrong, and there are not many cases out there that would be affected by it, so it should be fine correcting this inconsistency. But hey I'm no maintainer, your call to make this unnecessarily complex because of some paranoid fear ;)

[knocte]

unneeded trailing whitespace addition?

[smoothdeveloper]

Putting a note that with open static the line between function and method (and their overloads) will be blured.

I'm not sure if this warant adjusting the new parameter names, maybe invocation suits for both method and function without (wrongly) implying it will impact only functions.

[knocte]

2 remarks:

• When the config setting says "functions" does it also mean methods? (just asking because I remember you opened a github issue in some MS docs repo where someone was advocating for defaults that differed depending if the invokation was on a function or a method)
• When the config setting says "class constructor" does it also mean the invokation of it?

[knocte]

NOTE: you reduced ctor setting to one (SpaceBeforeClassConstructor) but here in the documentation there are still 4 ^

[Smaug123]

In general I'm pretty well in favour of this. Config settings are cheap.

G-Research coding standards here are essentially "use a space wherever possible, but sometimes it's not possible, so don't use a space then". Things like let foo = new Baz(). I think this looks flexible enough.

[nojaf]

@jindraivanek I reduced space before class constructor to one setting as it is something you previously had no control over anyway.

As @Smaug123 said, settings are cheap so I don't see the issue in this one-time setup.
Let me know if you have other names in mind.
Moving forward I would not add any new settings anymore in general to the CLI client as these can be passed via a configuration file.

[nojaf]

@jindraivanek current proposal after confirming the major version:

          SpaceBeforeParameter = true
          SpaceBeforeLowercaseInvocation = true
          SpaceBeforeUppercaseInvocation = false
          SpaceBeforeClassConstructor = false
          SpaceBeforeMember = false

I'll update the documentation in another PR as it should be revisited as a whole.

[knocte]

current proposal after confirming the major version:

Good to see the list of options being trimmed down!
But wait, if this is the result of pushing this feature to a "new-major version with breaking-changes" why not go all the way and also converge the 2 settings SpaceBefore{Uppercase|Lowercase}Invocation into one? Defaults differing depending on case is still ridiculous to me. Allowing breaking-changes in a new version should give green light to fix this.

[jgiannuzzi]

Hey @knocte, I am just reading this PR and I see some interesting technical opinion that you wrote, but wrapped up with patronising adjectives like "ludicrous", "paranoid", and "ridiculous".

It's counterproductive. In order to help make this PR better, and Fantomas in general, I would advocate for focusing on the technical matters, and keeping belittling out of it.

[knocte]

Sorry about that @jgiannuzzi

[nojaf]

why not go all the way and also converge the 2 settings SpaceBefore{Uppercase|Lowercase}Invocation

Well, this is purely an esthetic choice, both @jindraivanek and I came to F# from a C# background. And there it just feels weird to write myInstance.ToString ().

As @Smaug123 mentioned settings are cheap if you don't like you turn it off.

[knocte]

As @Smaug123 mentioned settings are cheap if you don't like you turn it off.

In this case I was talking about sane defaults, not explosion of settings ;)

[knocte]

And there it just feels weird to write myInstance.ToString ().

I also come from a C# background, and the coding guidelines I started with actually tell you to do this: https://www.mono-project.com/community/contributing/coding-guidelines/

[nojaf]

@knocte I don't see any example on https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions where they put a space before (). It is not listed as a rule but seems like an implicit thing throughout all the examples.

Not sure what why the Mono went a different route, but I hope we can wrap up the endless discussion about the settings...

[knocte]

I don't see any example on https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions where they put a space before ()

And in that guideline I don't see any example of where they do different things depending if the function being invoked is lowercase or not. I hope my point is clear enough now, because by the looks of the last comments, it's not ;)