dotnet-format - prettier (and eslint) for dotnet?
What took frontend development from a dark place into the light? Thousands of factors play a role, but I think one of the nicer ones are opinionated code formatters.
prettier solves a long running problem for a lot of projects. Since its inception in 2017, it quickly gained adoption for new JavaScript-based libraries. Prettier is an opinionated code formatter, with auto fixing. It is tool independent, and can be used from all developer environments, and the style can can be enforced in the CI pipeline!
No more “I changed a tiny thing in this file, and the auto-formatting changed everything” git diffs!
Avoiding broken windows and all that… Improving a simple thing as code formatting, keeps code tidy. No longer are bloated pull-requests because of a gigantic formatting pull-request. No more cherry picking out changes. No more “My IDE does thing differently, and does not care.”
dotnet format is an official Microsoft tool to solve formatting for dotnet code! In this post I’ll show you some quick steps to get started. Later posts will go into configuring dotnet format for the CI pipeline, and for your IDE of choice.
Using dotnet format
Installing dotnet format is easy enough:
dotnet tool install -g dotnet-format
This command installs dotnet format, and make it globally available through the dotnet format command.
You can now test it, by moving to a directory with a .sln file and invoking format with the --check command.
dotnet-format --check --fix-whitespace --fix-style warning --fix-analyzers warning
This prints any warnings! You can then manually go change everything, or run it again without the --check parameter.
By running dotnet-format without any arguments it defaults to fixing whitespace issues only.
--fix-style
Arguments: error or warn or info (fixes the given and higher severities)
The fix style argument will automatically fix style issues. This might be style warnings, such as readonly public -> public readonly and similar inconsistencies.
--fix-analyzers
Arguments: error or warn or info (fixes the given AND higher severities)
The fix style argument will automatically fix style issues from other analyzers, such as installed roslyn analyzer packages. This can be everything from no-unused code, to anything else installed as a roslyn packages.
More info on third party analyzers can be found here https://github.com/dotnet/format/blob/main/docs/3rd-party-analyzers.md
Thoughts about configuration
I would like the dotnet format formatter to be even more opinionated. Today it is quite limited in its formatting, and, for example, does not care about line length.
The elm language formatter is the golden standard here in my book. The elm formatter has Zero configuration options. It might be annoying for a while, but the upsides are greater than worrying about line spacing and indentation size. Every repository using it has the same code style. Jump in, press save, push to prod, without worrying.
More standardization is better, and the .editorconfig stuff they are doing with dotnet tools makes changing rules a hassle. Just cut it, and enforce a true dotnet foundation official code standard pleaseee.
Finale
I hope this gave you a quick introduction to the reasoning behind format and that you will consider using this in your projects! Its so much easier to contribute when you know that no person will have to complain about formatting changes and linting stuff in a review.
I recommend using the .editorconfig from the dotnet format repository (link) in your next dotnet project. It enforces some good guarantees.
Thats all for now!
Code Snippets are licensed under MIT No Attribution