In my recent posts, I’ve been exploring how Roslyn-based code analysers can help to make your code cleaner and more robust. I’ve tried to keep it relatively IDE agnostic so far. In today’s post, I’d like to talk about some of the pain-points involved with using code analysers in VS Code, as well as some of the progress being made by the community.
For my first and second posts about Roslyn-based code analysers, I deliberately avoided making reference to the IDE or runtime. As loyal readers will know, however, I’ve recently been using VS Code as my primary IDE. I’m also working predominantly in .Net Core. Having previously undertaken this sort of work in .Net Framework and Visual Studio, the differences are very apparent.
Before we begin…
Before I dive into the “pain-points”, it’s important to note that none of them has stopped me from successfully using code analysers in my project. Because the analysers run as part of the MSBuild process, the core functionality works fine wherever you can run dotnet build.
I’m also aware that I’m comparing a huge, commercial application (one that is deeply wedded to the .Net ecosystem) with a nimble, free, open-source alternative. These are inevitably going to be very different experiences. If and when I want the heavy-duty experience, I can (and do) fire up Visual Studio.
This post isn’t a plea to reinvent Visual Studio. Instead, it’s a continuation of my reflection on the differences between the two and a celebration of the work being undertaken by the open source community to provide ways to bridge the gap.
How things work in Visual Studio
OK, so we’re all on the same page, let’s recap the functionality that Visual Studio offers when it comes to code analysers.
- Visual Studio surfaces code analyser rule violations in the editor using IntelliSense “squiggles” and “lightbulb” tooltips. This means you can more easily locate the issue in the code.
- When a squiggle is present, Visual Studio will often offer a quick “code fix” in the form of an automatic correction/refactoring.
- Visual Studio has built-in support for managing rulesets , with graphical interfaces that control how violations of each rule are handled.
Together, these features add up to a fairly seamless experience. Code analysers feel like first-class citizens in Visual Studio.
None of these features are present in VS Code out of the box, or (at this time) even available as an easily-installable extension.
Pain-point #1 – fixing violations
As a “pain-point”, I’ve lumped together the first two bits of functionality from the list above: squiggles and code fixes. They’re both to do with responding to violations. Squiggles and tooltips make it easy to know what you’ve got wrong in context. Whilst you’re there, the suggested fix is easy to apply.
Since the support for code analysers in VS Code amounts to running MSBuild and displaying the output, our workflow (out of the box) is a little different here. Less “pair programming with my robot colleague” and more “lather, rinse, repeat, accidentally violate a new rule whilst fixing another”.
If you’re willing to jerry-rig your setup a bit though, you can get a bit closer to the Visual Studio experience. By butchering the Roslynator plugin for Visual Studio, it’s possible to persuade Omnisharp to offer up some code fixes and refactorings
I also note that the wizards of the Omnisharp team have been making strides towards supporting Roslyn analysers directly. In fact, there’s a pull request that’s chugging along nicely.
Pain-point #2 – managing rulesets
The second major pain-point for me is the management of my ruleset. In other words, adjusting which rules are applied and what severity to give to violations of each rule.
As mentioned above, Visual Studio offers a graphical interface for this. (In fact, it offers at least two – one in the project properties and one in the solution explorer.) This makes it easy to turn whole rulesets on and off, as well as managing the severity of individual rules.
In VS Code, you’re pretty much left to your own devices. Sure, you can create a .ruleset XML file and put whatever you like in it, but it’s all very manual.
In my last post, I described my method for managing the deluge of violations that jump out when you first activate code analysis on a legacy project. Part of this process requires the creation of a spreadsheet to turn the output of MSBuilt into the XML required by my ruleset file. It works, but it’s a couple of steps too many to be accessible.
I’m not aware of any open source projects that are targeting this aspect of the workflow. If you are, please let me know.
I’ve toyed with the idea of creating my first VS Code extension that offers a GUI for this sort of activity. I’ve also considered a stand-alone CLI tool that could potentially provide the muscle to a VS Code extension. I’ve even wondered if I shouldn’t just create a web-based ruleset manager… If you want to collaborate on any of these ideas (or perhaps you have a better one!) then please get in touch.
Summary
Don’t get me wrong, one of the things I like most about VS Code is the absence of smoke and mirrors. It’s a stripped back experience that reconnects you with the tooling.
Sometimes (just sometimes) I find myself craving the bells and whistles that Visual Studio offers. Usually, some bright spark has already made an extension that scratches the itch, but sadly we still have some gaps when it comes to code analysers. I suppose it’s just a little bit too niche?
I’ll carry on working with code analysers in VS Code and will keep a close eye on how the tooling develops over time. I may even (if I can carve out the capacity) turn my hand at making some brand new tooling. Watch this space!
Have you been using code analysers in projects you’ve worked on is VS Code? How did you get on? Let me know in the comments below.
Top comments (0)