Roslyn formatter should offer an option to enforce a maximum number of columns per line

[siegfriedpammer]

One feature I am missing in Visual Studio is being able to automatically enforce a maximum line length. That is, if a line of code is too long, it automatically gets broken up into multiple lines. I often find myself writing very long lines of code (up to 200 columns). However, I don't want to have to think about arranging and breaking up the code. This bad habit is enforced through very large monitors.

TL/DR: Please add support similar to clang-format options like ColumnLimit and the Align* and BreakBefore* group of options. (see https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
The reason I don't want to use clang-format is because it does not support all C# language features (for example LINQ clauses are not arranged nicely).

Example 1)

Parameter lists/declarations should automatically be split into multiple lines and indented/aligned properly.

Before clang-format:

After clang-format:

Example 2)

Expressions, conditions and comments should be split into multiple lines and indented/aligned properly.

Before clang-format:

After clang-format:

[sharwell]

Note that the use of tabs for indentation and spaces for alignment is not currently supported by the Roslyn formatter, but is covered by #24031 (comment).

[jmarolf]

related to #15406 and dotnet/format#246

[sharwell]

@jmarolf I thought there was a duplicate but I couldn't find it. Can you copy your proposal to #15406?

[sharwell]

Duplicate of #15406

[siegfriedpammer]

So enforcing a hard limit on line length is not actually possible in the language due to:

• existing indentation rules: what if the user is 20 levels of indentation deep and therefore goes over the desired column width? Basically anywhere enforcing a column limit would violate another style rule we would need to decide who take precedence
• literals (especially string literals): while we could attempt to split string literals that exceed the column width it seems that this could potentially be re-writing the users code more than they intend

For me, there is no need to modify single tokens/literals. If a single token + indentation exceeds the column limit, I would expect the formatter to break after that token. The only exception would be semicolons, these should be kept on the same line as the last token.

I like your proposal a lot. Thank you!