format
format copied to clipboard
dotnet
Prettier-style line breaking
It's my understanding the the project doesn't do line breaking the way Prettier does: Inserting and removing line breaks depending on the length of the resulting lines.
I can't find a rationale for this and I can't find a ticket mentioning this.
It's technically easy to implement (using Roslyn), but it's not entirely independent from other formatting jobs (eg. whether opening braces should always be on a new line).
So what's going on? Is there no love for Prettier's approach?
I've never seen an automated line breaking strategy that wasn't also a readability breaking strategy. In other words, the tool produced worse results on average than if it didn't change wrapping at all. I have some theories about things that might change this, but overall this is a very, very hard problem.
I haven't seen Prettier specifically, especially on C# code. Is the line break strategy documented in detail?
It can't do C# and my good impression comes from what it does to JavaScript.
I just looked at the docs and it says it used this paper. That seems a bit more complicated that I would have thought at first glance.
I can tell that it is at least doing this: When you have a node with more than one child (array literal elements, function arguments, etc.) and it can't fit it all in a line, each child goes on its own line. I've seen this to be the crucial issue, but maybe there's more to it.
basically my question is how well does Prettier handle re-flowing comments in javascript? I've read the paper you linked but it doesn't address this problem. The approach they use mentions an AST, but ASTs don't contain comments. Handling comment layout is one of the problems we will need to solve if we want to tackle this.
prettier handles line breaks very well. i know a lot of teams who enforces prettier formatting as validation gates in PRs. it completely removed the discussions around code style for my team as well. it works so good that i‘m not aware of one single example where prettier did a bad job with typescript projects.
if we could get C# code to the same high quality standard it would save us a lot of time.
looking at this test it doesn't appear to handle comments at all. You can even get it to place things outside of the minimum width in pathological cases.
I believe that re-flowing syntax can be done. The issue every time we research this on our side is how do you correctly re-flow constructs that do not have syntactic meaning such as comments. If someone has a proposal for this I am all ears.
@jmarolf They talk about why they don't do comments here: https://github.com/prettier/prettier/issues/265
I'm not sure why a lack of support for comments renders the other parts of the formatting useless.
Prettier also still leaves the programmer some other kinds of freedom, such as empty lines for separation of statements.
I'm not sure why a lack of support for comments renders the other parts of the formatting useless.
A re-flow strategy that only handles some language constructs is not a complete solution. If I run dotnet format and my code is less readable I am not going to be inclined to use dotnet format.
That doesn't mean we can't start on this though. @jtheisen if you submit a PR for Prettier style re-flow I would be happy to work with you to get it in.
I assume if this was implemented we would want to specify the column width in the editor config file. presumably one labeled printWidth?
Thanks for the offer. We'll see if I get struck with dedication.
Btw, why is the formatter operating on a project rather than a single file?
@jtheisen there are some formatting questions that require semantic information and there fore need to know settings from the project file. We could re-write things to allow a subset of the rules to work without a project file being present.
Can you be more specific? What rules require more than the file in question?
For example, there is a style rule that allows you to prefer keywords such as int over class names such as Int32. Without the information in your project file we cannot determine if a class is the Int32 class from the framework or just a similarly named class that you or a nuget package has defined. I can go through the style rules and give you a list
I concur. A zero config, catch all, highly opinionated formatter for C# like what prettier is for JavaScript/TypeScript would be an absolute game changer! 🚀
I found this repo looking for a prettier-like solution to my C# code. Prettier is the de facto formatting standard for everything JS/TS and it's awesome! I really really hope this will become something similar ❤️
About the single file formatting. I believe this to be an essential feature, because the next step is to have git pre-commit hooks run formatting on every file committed. That'll be odd when having to run on folders. Isn't looking for the project file up the directory tree an option? Much like editorconfig looks for its config?
@snebjorn Prs have been added in the meantime @JoeRobich I believe it is possible to run this tool on a single file now correct?
@snebjorn You can invoke dotnet format against a single file with the following command dotnet format -f . -files {relative-file-path}
- the -files option will become the -include option in 4.x and switch from being a comma-separated list of relative paths to a space separated list of globs
I concur. A zero config, catch all, highly opinionated formatter for C# like what prettier is for JavaScript/TypeScript would be an absolute game changer! 🚀
If you've never used a language with a community-standard auto-formatter, it's hard to overstate how big of a deal it is. This is by far my top feature request across the entire .net ecosystem. I think it would be a big win for .net
We currently use the resharper cli in a hook to format our solution, which works well for line wrapping (and is free to use) however it is very very slow (even when filtering to just staged files).
I would love to switch away from it as dotnet-format performance is considerably better, however line wrapping is a deal breaker right now.
My 2 cents on comments would be that if the rest of the code is wrapped you are more likely to write properly wrapped comments. If they aren't wrapped automatically it is still a huge improvement.
FWIW We also use prettier+eslint to format out react+typescript web frontend so have experience with that.
After two out of .Net and spending my time on python. I can confirm that language like that exists. The python community has a pep that defines the code formatting pep8. Today the community is using a tool name black. This simple convention that defines as well the max line size simplifies a lot of code readability and developer won't have a argue about the code format during code review. I'm looking forward to seeing that on C# as well
There is a prettier csharp plugin, it's unfinished though: https://github.com/warrenseine/prettier-plugin-csharp
upd - this one is in development: https://github.com/belav/csharpier
clang-format does this very well for C++ code and has been a game-changer for our development at my current place and at Spotify, at both places we enforce it as a PR-gate.
This feature would be a game changer for our team. no we are forced to use JB CLI tool and its proprietary rules
This feature would be a game changer for our team. no we are forced to use JB CLI tool and its proprietary rules
https://github.com/belav/csharpier is the game changer you are looking for, it really is like prettier but for C#.
CSharpier is awesome, but the fact that it doesn't seem to use dotnet analyzers (I'm assuming here because it doesn't work with dotnet format) makes it always a bit silly to have 2 tools and also have to use one or the other (for example in VS Code, either use omnisharp formatter or CSharpier extension formatter).
This really belongs to dotnet format, which does already have style / whitespace aspects - or Rosluyn analyzers in general.
If you configure your analyzers nicely and maybe bring in some 3d parties like Roslynator, this issue becomes the most, even the only, obvious difference that makes tools like Resharper, etc. shine compared to Roslyn-based solutions.
What‘s your use case with dotnet analyzers? I think you don’t need the overhead of those analyzers to format code files. Dotnet format is pretty slow and still has inconsistent formatting. Prettier does a pretty good job by being fast and consistent. IMHO that‘s the reason why it is so successful. Completely rewriting the code with changed syntax shouldn‘t be a part of formatting.
FWIW I tried a combination of csharpier + format, in that order, because we'd really want consistent line breaking but also want most format features plus we do get the reationaly behind opinionated formatting but the shift from if( stuff ) to csharpier-stylle if (stuff) is a bit much for a huge codebase. Unfortunately doesn't work 100% (as in: repeatedly applying still changes some whitespace) though it's close.
csharpier has some edge cases (it failed on what seemed to be a totally innocent file in my experience), but the most annoying thing about it is that it seems to cause some issues with roslyn format options, that csharpier even recommends turning off the format analyzer. This is a bit disappointing even if it makes sense.
It also resists the idea of configurability (like prettier when it first started, later prettier added configurability I think), which wouldn't work for everyone.
@stinos & @Meligy
Unfortunately doesn't work 100% (as in: repeatedly applying still changes some whitespace) though it's close.
csharpier has some edge cases (it failed on what seemed to be a totally innocent file in my experience)
I haven't seen any of those problems with CSharpier, maybe you could create issues for your problems?
It should play nice with other linters according to https://csharpier.com/docs/IntegratingWithLinters.