ifs, lambdas, type declarations, etc.

[giedriusbruzas]

A few notes that I have regarding this great piece of work. Hopefully not too late and not too pretentious.

if

• I think there's more to expressions than just small expressions and large expressions. Could this be clarified a bit? How about differentiating between multi-line, single-line short (simple values) and single-line long (function evaluations) expressions?
• When e1 and e2 are both single-line (short or long) expressions, I almost always choose this:

  if cond
  then e1
  else e2

  I like the way it looks like a match. then and else are same length - great coincidence (or design!) IMHO. I guess one drawback is that you kind of need IDE to highlight the relevant bits to look really nice.
• I would personally avoid this even if expressions are of different size:

  if cond then e1
  else
      e2

  I prefer e1 and e2 to be at the same distance from the left side of the window (on the same level). The example above breaks the logical structure of the construct.

Lambdas

Why not like this:

let printListWithOffset a list1 =
    List.iter
        (fun elem ->
            c1) // When c1 is multi-line
        list1

Or:

let printListWithOffset a list1 =
    List.iter
        (fun elem -> c1) // When c1 is single-line
        list1

This matches nicely with the function parameter application formatting guidelines. No dangling parentheses.

Other notes

• One-liner match example looks complicated. Is there a good reason not to break that into three lines?
• I'm missing guidelines on how to format explicit type declarations. Especially of interest are the more complicated cases - multiple parameters, generics, functions.
• I see value in the multi-line comments. When changing the content of the comment I often need to break the lines in different places than previously. In those cases the // are in the way.
• And finally, perhaps all of my questions could have been avoided :) I think it's very valuable with controversial topics such as style guides to have argumentation close at hand to justify the choices taken in more detail. Not necessarily in the guide itself, but perhaps in a separate article, or footnotes?

Again, thanks for the lovely work.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8c09996f-24ac-cf39-ef43-d7909cbc2b89
• Version Independent ID: 1efdd523-8552-6421-e149-74f76826ef8f
• Content: F# code formatting guidelines
• Content Source: docs/fsharp/style-guide/formatting.md
• Service: unspecified
• Product: dotnet-fsharp
• GitHub Login: @cartermp
• Microsoft Alias: phcart

[cartermp]

@giedriusbruzas Thanks for the feedback. Let me address it here:

if expressions:

I'm a bit hesitant to change this myself, but I would happily take a look at a PR which covers the points you've mentioned. I'm not opposed to them, but I'm also not sure I agree with them enough to make changes myself. However, depending on how it is worded, I can absolutely see what you're saying here.

Since this document is a live article and absolutely subject to change based on feedback, feel free to make that PR and how it's worded.

lambdas:

100% agree, and in fact, I'm going to replace the current guidance with what you've laid out. I'll link the PR once it's out.

Other notes:

• I'll just remove the one-liner example. People can figure out that this is possible on their own, but I think it's a bit dangerous to suggest it outright.
• Explicit type declarations is interesting. I'll think about what to put here, but it may be a separate PR.
• I'll add something about multi-line comments being useful, but we still want to go with the guidance for prefering // so that it stays in spirit with .NET.

Your feedback and questions are much appreciated, and I definitely value them 😄. Thanks for offering them, despite the space being almost controversial by its nature.

[cartermp]

Link #5753

[cartermp]

Let's brainstorm a bit on the if section. It's currently short (and hopefully sweet) to cover what I believe to be a common question beginners have w.r.t how to format the expressions. But you're right that there is more to it than just how long the expressions will be.

I think the following are considered by people:

• Size of each expression
• Aligning stylistically with other code in their codebase (e.g., looking similar to a match expression)
• How long (character count) a line is before it deserves a line break
• If expressions should be aligned with each other or not

What else do you feel are considerations?

[giedriusbruzas]

@cartermp

First off, after reading your comments, I realized that I might have looked at the guide a bit differently to begin with. To me, it is about two things. As a starting point for beginners, but also as a guidance to get everyone aligned on the same style. This was my primary motivation, FYI. I do hope to be challenged before we actually do any changes.

Since this document is a live article and absolutely subject to change based on feedback, feel free to make that PR and how it's worded.

I can prepare something, but it will probably take a little while before I get to it.
Here's the changes that I would make:

• Change the wording a bit: instead of small / large, use single-line / multi-line (where appropriate) and short / long.
• Remove this:

  if cond then e1
  else
      e2
  

  and this:

  if cond then
   e1
  else e2
  

• Add this instead:

  if cond
  then e1
  else e2
  

What else do you feel are considerations?

Well put, I can't think of anything at the moment, but I'll let my brain process this a bit in the coming days and get back to you, if I remember anything important.

if section definitely needs challenge, but I'm not sure how to get that. Do you think a PR would help?

[mairaw]

@cartermp any updates to this one? Can you assign a milestone?

[JRAlexander]

@cartermp any updates to this one? Can you assign a milestone?

[cartermp]

Hey there, sorry for the lack of response.

@giedriusbruzas please do submit a PR and we can review there.