Roslyn: C# code not correctly indented

[mkrueger]

Reformatting the file doesn't correctly re-indent the second .Foo (); line.

using System;
namespace SwitchvoxSoftphone
{
    public class SampleClass
    {
        public SampleClass()
        {
            this.Foo()
                             .Foo();
        }

        SampleClass Foo()
        {
        }
    }
}

[Pilchie]

Our formatting does not enforce placement of continued lines. Instead, hitting enter suggests a default indentation, and formatting tries to preserve the offset relative to the beginning of the statement, but never forces it to a strict indentation.

[banshee]

That's horrifying. Formatting has to fix the formatting; that's fundamentally what it does. Leaving random indentation means you're not a formatter. You're, hmm, a vague kind of suggester that sometimes does a thing?

[weltkante]

Ah, that explains the repeated issue I have with formatting delegates passed to function calls (which usually involves continued lines) and why I have to go around pressing "enter" in random places instead of just being able to invoke the "format document" command.

Maybe there needs to be a second command "really format document" which enforces default indentation instead of just suggesting it when pressing enter ... right now I have to fix stuff up manually when VS doesn't want to format it properly; alternatively I'm considering https://github.com/dotnet/codeformatter but I'm hesitant due to the work involved to make it use our coding style.

[miloush]

might be relevant to #9702 resp. #779

[renzska]

I'd love to see an option for this. Any plans to make this an option at least?

[CyrusNajmabadi]

PRs welcome. :)

[weltkante]

@CyrusNajmabadi up-for-grabs on a closed issue?

[CyrusNajmabadi]

Sure. If you want to come with a PR that addresses this, i'd be happy to take this.

[SylwesterZarebski]

Why is this issue closed? Multiline formatting is virtually non-existing. Even VSCode has better formatting in this regard...

[weltkante]

@SylwesterZarebski explained in the first response

Our formatting does not enforce placement of continued lines.

In other words, the issue was a bug report against a non-existent feature. To make a feature request out of it there probably needs to be more information provided on the desired functionality than this issue currently has.

(Also I don't know if there is any point in starting a feature discussion on a closed bug report, might be better to make a new issue for a feature request discussion and perhaps refer to this if you need to, but I'm not doing a lot on this repository so I don't know how they prefer to handle it.)

[SylwesterZarebski]

Then it should be labeled as Feature request with discussion, what should be done, not closed.
This issue should be reopened and labels set accordingly instead of making mess with multiple duplicates (i.e. formatting of multi-line array initialization which has multiple issues, some closed, some not for years).

[banshee]

The problem is that it's clear to people who aren't on the team that this is a serious bug and in no way a feature request. Formatters have one job to do, and the C# formatter doesn't even try.

[sharwell]

@banshee The problem is not that people disagree on whether this is a bug. The problem is that people disagree on what the fix is. 😄

Any change in this behavior is likely to produce large diffs when users reformat their solution with the changes in place. If we make the wrong decision (an absolute guarantee considering that several known viewpoints are incompatible with each other), the impacted teams will have a very negative experience with the update. It's much easier to not do anything, with the following potential solutions:

• Today: users can write analyzers that check almost anything, including whitespace code style. It doesn't run with Format Document, but it's generally well-received and command line automation is coming soon to dotnet-format.
• Future: we want to make the formatter itself extensible. See #31691 for the high-level tracking issue. Once this is resolved, a team could write custom formatting rules that run whenever Format Document is invoked. We have several issues linked to that story to help verify that the extension API meets a diverse set of formatting needs.

[miloush]

Roslyn never did this and pre-Roslyn editor didn't do it either. Sounds like a new feature to me. Not only that, I would take a guess that this formatting has been consciously avoided to allow developers align things in any weird way they do. Nothing is more annoying than auto-formatting ruining your crafted alignment.

Even in the OP example, there are at least three valid alignments - start of the previous line, dot on the previous line (fortunately there is only one) and after the closing parenthesis. What if there is a comment on the previous line that begins at the same place as the second line dot?

[SylwesterZarebski]

Then it is needed to introduce new configuration options, like current ones. Or wait for #31691.
Nevertheless, this issue should stay open till resolving.

[CyrusNajmabadi]

It's by design that things are working this way. The potential solution for people is to write their own extension for this. Alternatively, you could help contribute toward #31691.

[SylwesterZarebski]

Then this design is wrong and needs to be revisited.

[CyrusNajmabadi]

Then this design is wrong and needs to be revisited.

The proposed solution is https://github.com/dotnet/roslyn/issues/31691. You are welcome to help contribute to that. Thanks!