Seven reasons that Roslyn-based Code Analysers are awesome

Static analysis can be a great way to ensure that your code is robust and clean. Unfortunately, many static analysis tools are prohibitively expensive and/or fiendishly complicated. In today’s post, I’d like to talk a little about Roslyn-based code analysers, which cost nothing and are easy to set up. In fact, keep reading for seven reasons that they’re ace.

Roslyn? Code analysers?

Let’s get a bit of background out of the way. What exactly do I mean by Roslyn code analysers?

Well, Roslyn is the “Compiler-as-a-Service” that transformed .NET compilation from a magical black-box into an interrogable, extendable framework. As the compiler, Roslyn canonically knows everything relevant about the syntax and semantics of your code. By opening up the compiler in this way, the .NET team made it possible for other code to access this definitive understanding of the code.

The code analysers I’m referring to are Roslyn-based libraries that can flag where your code breaches their guidelines. Each analyser comes with its own set of rules. The “rulesets” you install are run whenever your code is built. It’s possible to adjust the severity of rules, or even ignore them. It’s also pretty easy (apparently) to create your own analyser by tapping into the Diagnostics API.

Why they’re great

1. They cost nothing. As regular readers will know, I’m a fan of NDepend for static analysis, but I have to admit that the cost can be off-putting. Roslyn-based code analysers can’t compete with the power of NDepend (or ReSharper), but they are completely free.
2. They are simple to set up. Literally just adding NuGet packages. You could do it in your sleep. (Don’t believe me? Keep reading.)
3. They’re really fussy. They spot things that even the most pedantic human would miss in a code review. Whether it’s a super-subtle design point or simply incorrect spacing, a code analyser will spot it.
4. They don’t forget. Would you remember the dangers of using ToLowerInvariant() or why you should use ToUpperInvariant() instead? No? Me either, but luckily for us CA1308 does.
5. They aren’t polite. Ever been tempted to let some minor annoyance slide for the sake of office politics? We all have. It’s only human. The good news is that code analysers aren’t human and don’t care about hurt feelings. It’s not personal!
6. They are great at starting a conversation. Don’t like a rule? Well, perhaps we can set it to be ignored in our ruleset. But first, you gotta convince me. Let’s have the discussion and make sure we all understand why the rule is there and what the implications might be of ignoring it. Let’s make this an active and collective decision.
7. They work wherever you build your code. Once configured, your analysers will run whenever your code is built. Whether the build happens to be taking place on your laptop or in your CI system, you can relax in the knowledge that no-one is going to check-in code that violates the rules you’ve agreed upon.

See? Code analysers are fantastic! They can seriously help make your codebase tidier and more robust, and then they can help you keep it that way.

OK, I’m sold – how do I get started?

As with many things in the world of software development, the hardest thing about code analysers is other people. You’ll need to convince them of their value and make sure the whole team has bought in. Once you’ve done that, getting the tech set up is a breeze…

1. Choose the analysers you want
2. Install them via NuGet
3. Restore the packages
4. Build your code
5. Review the output
6. (Optionally) Create a custom ruleset file to adjust message severity

It really is that simple. The two that I’d recommend as good, general purpose code analysers, are the venerable duo of FxCop and StyleCop.

If you’re working on a new project, you’re now good to go. If you’re retrofitting code analysers to an existing project, stay tuned for an upcoming post!

Wrapping up

Hopefully, I’ve communicated the benefits of using Roslyn code analysers to automatically apply rules to your code.

For me, part of the appeal is that the main rulesets are effectively distilled wisdom from some Very Smart People™. They aren’t gospel by any means, but they’re a good place to start a discussion and usually seem to come from a sensible place.

I like to think of code analysers as being on the same spectrum as unit tests. Both are automated checks we can add to our codebase. Robots, in essence, that want to help us keep our code as clean and robust as possible. Of course, compared to unit tests, automated code analysis can be a lot quicker to get off the ground.

As I alluded to above, the hardest thing is often the “soft skills” aspect – getting the buy-in of your colleagues. There’s no quick fix for this, but I’d suggest coming at it from a place of humility; no-one wants to feel like the introduction of code analysers is a judgemental response to their own bad code. Be positive about the whole thing and focus on making your (plural) code more robust.

Another tricky part of the puzzle can be if you’ve decided to add code analysers to an existing codebase. Spoiler alert: you’ll drown in messages. I’ve used an Excel-based system to help with this, which I’ll share in my next blog post!

I’ll be back soon with more posts on the subject of Roslyn code analysers, but that’s all for now. Thanks for reading! I hope you found it useful. If you’ve used code analysers before, perhaps let me know how you got on in the comments below. In fact, why not let me know your favourite rule?