Comments (27)
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.
from fslang-design.
Decision on (4) is here: #663
from fslang-design.
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"
from fslang-design.
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
) =
...
from fslang-design.
@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.
from fslang-design.
@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?
from fslang-design.
@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?
from fslang-design.
I've repurposed this issue to be specifically about formatting of argument lists
from fslang-design.
@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) =
...
from fslang-design.
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?
from fslang-design.
@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.
from fslang-design.
Related Issues (20)
- [style-guide] Better control of pattern match handlers and line breaks. HOT 34
- [style-guide] space around SynType.StaticConstantExpr HOT 3
- [style-guide] Units of measure should format like expressions HOT 7
- [style-guide] Guidance for code quotations HOT 1
- [style-guide] when expressions in match clauses HOT 15
- [style-guide] Format mutation expressions on their own line HOT 11
- [style-guide] Presence of shebangs in scripts HOT 8
- [style-guide] prefer leading rather than trailing operators HOT 8
- [style-guide] Chain of (fluent) calls HOT 7
- [style-guide] Multiline base constructor call HOT 2
- [style-guide] Stroustrup bracket style HOT 28
- [style-guide] Multiline type annotations HOT 5
- [style-guide] Advice on Attributes needs improving HOT 1
- [style-guide] Parameter owner patterns should be consistent with prefix application expressions HOT 10
- [style-guide] Multiline application in patterns HOT 2
- [style-guide] Breaking of complex pattern match expressions HOT 1
- [style-guide] Lambda closing paren defaults HOT 5
- [style-guide] Treat cast operators :> and :?> as pipe operators
- Bug: Compilation error when multiple interface generic types are matched using `or`.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fslang-design.