Roslyn: Feature request: Allow me to specify a desired max-column that code shoudl be wrapped against.

[CyrusNajmabadi]

I'd like this both for code and for comments.

Right now there's nothing that helps me when code gets really long. This is problematic with features like "implement interface" where an interface method might end up super long, making it tough to use in the IDE and in PRs.

After generation, i have to go in and manually wrap things. I'd like to have a preference (ideally project scoped) that says what column we try not to go past. Features like formatting/generation should attempt to respect this wrapping column when possible when they have items they can wrap. For example, method parameters would be a suitable wrapping entity.

Thanks!

[Pilchie]

For reference, I implemented this back in VS2005, but we ended up pulling it out. It ends up leading to another explosion of options for how to do the wrapping:

• 1 parameter per line, or as many as fit
• First parameter on the same line as the method or not?
• What is the indentation of the wrapped line
• Should expressions be wrapped before or after operators,
• etc.

I'm not saying it's impossible, just that it's not nearly as simple as a single option for that the line length should be.

[JeffBail]

It would be nice if this could be implemented so as to support the max_line_length editorconfig parameter already supported by many editors.

[jmarolf]

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 takes 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

Here is a simple (and incomplete) proposal:

• syntax
  
  
  
  • If an expression exceeds the column width the entire expression should be re-flowed for consistency
  
  
  • re-flowing syntax to the next line should (in general) increase the indentation by one
  
  
  • member access expressions
  
  
  • should not increase indentation if they are part of the same set of member access expressions
  
  
  • lambda and delegate expressions
  
  
  • should increment the indentation again and be put on a new line only if the column length is exceeded. Otherwise they should be considered a part of the member access expression
  
  
  • parameter lists
  
  
  • we have several schemes of wrapping parameter lists. if none are specified as preferred by the user in their editorconfig we should set one as the default.
  
  
• trivia
  
  
  
  • multi-line comments: This is the easy case as they can be moved anywhere, use normal wrapping rules
  
  
  • Remove all new lines in multi-line comment
  
  
  • Find the closest word to the column limit and insert a new line
  
  
  • reflow comment to current indentation level
  
  
  • repeat for new line
  
  
  • single line comments: I would just punt these in the initial implementation. The only other option would be attempting to convert them to multiline comments as described above which would likely be changing more than the user wants.
  
  

[snebjorn]

I feel these concerns have already been solved by prettier to a satisfactory degree

You can play around with it here https://prettier.io/playground/ (no it doesn't work with C#)

[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!

[jmarolf]

@snebjorn prettier focuses on formatting in a single style for javascript. Whatever this formatting becomes it will need to interact with the many formatting options that already exist today for C#. I do not know how comparable to two situations are.

[CyrusNajmabadi]

Small point:

If a single token + indentation exceeds the column limit, I would expect the formatter to break after that token.

That's not what i woudl expect. I would expect to break before teh column except in the case that breaking before would put the token on the same column as the line it was on (and thus would still be in the same problematic state). i.e. we should only cross the column as a last resort.

[snebjorn]

@snebjorn prettier focuses on formatting in a single style for javascript. Whatever this formatting becomes it will need to interact with the many formatting options that already exist today for C#. I do not know how comparable to two situations are.

Sorry I mistook this as the https://github.com/dotnet/format repo

[jmarolf]

@snebjorn no problem. Part of this discussion is trying to define what to goals are and how they differ from what other successful formatters do.

[snebjorn]

Meanwhile a JAVA plugin have appeared for prettier. JAVA and C# have pretty similar formatting concerns so perhaps it can be used as an inspiration :)
It's still early days, so it's not perfect.

Here's a playground https://shaolans.github.io/prettier-java-playground/

The link might change or go stale so here you can track changes https://github.com/jhipster/prettier-java/issues/193