C# code formatting with Csharpier

A little bit of history

I have started off my career as a backend dev and quite fortunately found a great match with my beloved Dotnet and C#. But curiosity led me out of my backend developer shell, and I had a wild idea that I could perhaps do the frontend myself, seeing how others handle it with ease.

The transition was fun and has shifted my view of software development to be more holistic. I could also see the benefit of sharing ideas on how to tackle the development challenges between the different stacks.

But one thing left me with a strong sense of envy.

An endless debate

Now, like every other developer, over the years, I’ve developed an opinion on how the code should look (my code) and how it shouldn’t (other people’s code).

The dotnet ecosystem didn’t help this much either. As there wasn’t a unified set of rules and Visual Studio didn’t provide many hints back then. It did some formatting and gave you a few hints, but that was it.

You could extend it with ReSharper (which was, for some reason, considered a must-have) and get a little bit more rules. But that was still far off the perfect solution.

And there was the rabbit hole of defining your own rules, and you bet that hole was deep; there was a configuration probably for anything you could think of. And with every toggle, the probability of you and your colleagues not agreeing on it was going up!

Treasures from the frontend expedition

Hadn’t I done my adventure towards the frontend lands, I would’ve probably accepted this as a fact and moved on. But for some reason, the situation was a little bit different in the frontend ecosystem. They didn’t face the same challenges as I did with my beloved dotnet.

The reason for their peace of mind was quite simple - they had a tool called Prettier. I know that there are other tools on the market, but I’ve mostly encountered this one. Prettier had solved this for them and didn’t give them much room to discuss. As Prettier is quite strict when it comes to its configurability.

So I thought to myself that would be a nice tool to have for my beloved language as well; perhaps I can write myself one. Fortunately, I stopped that thought soon enough and began googling instead.

And what do you know, someone actually didn’t stop at the first thought and developed the tool - and thus I found Csharpier.

A quick check

I love tools that are quick and easy to try out, and in this case I wasn’t let down.
A quick install via dotnet tools.

dotnet tool install csharpier

Followed by a format command in the root folder of your project.

dotnet csharpier format .

And in a few minutes we can see the results already. If you are using Git in your repo, you can compare the differences between your former style and the new style you’ve applied.

One style to rule them all

Now, as I was saying, more people working together means more opinions on how the code should be formatted. The best way to win this war is not to take part in it at all.

Prettier and Csharpier solve this issue with elegance—by not allowing any configuration options.

Fair and simple, no politics dictate which style should be preferred. No time is wasted on voting on whether you should put the parameters on separate lines or keep them together. You only get one choice, and it’s either a yes or a no.

Although you get a few options, like printWidth and useTabs. But I hope you can agree on a few items, right? Right?

Integrating Csharpier into your project

Apart from loving discussions about code style, we programmers are likely to be lazy. Asking someone to run the format command before pushing their code might succeed in 80% of cases, but the remaining instances are essentially a lost battle. Once again, the best way to win this fight is to not take part in it.

Given that you’re using a Git repo, a simple pre-commit hook might do the trick. You can write your code as ugly as you’d like, and when you commit, it all gets corrected automagically.

The setup for the pre-commit hook is quite simple.

First of all, let’s install all the required tools, which in our case are going to be Csharpier and Husky.NET.

dotnet new tool-manifest
dotnet tool install csharpier
dotnet tool install Husky

Then run this command to create a “.husky“ folder with task-runner.json and pre-commit files:

dotnet husky install

Then you need to change .husky/task-runner.json as follows:

{
  "tasks": [
    {
      "name": "Run csharpier",
      "command": "dotnet",
      "args": ["csharpier", "format", "${staged}"],
      "include": ["**/*.cs"]
    }
  ]
}

Last, but not least, you need to add the Husky command into a pre-commit file:

dotnet husky add pre-commit -c "dotnet husky run"

Now each “.cs“ file that is staged in Git (git add .) will have the Csharpier formatting applied to it.

Making life easier for future developers

To automate installation for other developers, run this command to attach Husky to your project.

dotnet husky attach <path-to-project-file>

You can also decide to attach this to multiple projects in case one gets deleted, but the decision is up to you.

Build pipelines

We have a pre-commit hook that formats the code before it even gets pushed. So, we don’t need to format it in our pipelines. Set an environment variable to HUSKY=0 in your pipelines to disable it.