This is a. NET focused post.
It’s great to see the things that people are building now that the C# compiler is open source. We are literally swimming in tools, which isn’t a bad thing but I do need to consider how many tools I have in my development pipeline. I currently use ReSharper and Prefix at at work on a daily basis. NDepend and PVS-Studio on a weekly basis, but only on personal and open source projects. Can I add another to the mix? Sure! This one is not intrusive and doesn’t clash with ReSharper or VS code hints. There’s also some slight humour in the way it reports code related issues.
Usage through the IDE
The options for using this tools aren’t varied just yet, but it does support the three most popular IDE’s:
- Visual Studio
Comprehensive language support comes from the IntelliJ and Eclipse IDE’s. If you’re using Visual Studio (VS), then you’ll get a nice rule set for C# and VB.NET.
You can also use it at the command line which is perfect for an continuous build pipeline. Analysis needs to be done through MSBuild as their command line tool doesn’t currently work as advertised. Running the analysis is easy enough and there’s an XML file I can process at the end of the build to produce reports or store somewhere for analysis over time. One thing to note is that the XML report will be generated once per project directory.
msbuild MySolution.sln /p:RunCodeAnalysis=true /p:CodeAnalysisLogFile=MyXmlReport.xml
Interacting with Rules in Visual Studio
There’s an extensive list of 214 rules for C# and 62 for VB.NET although they aren’t all enabled by default. Rules can be customised so that one rule set runs for one project and another rule set for another project and I’ll explain how shortly.
In true VS fashion code which violates one of the rules gets a squiggly line underneath the line of code which can then be dealt with by pressing
There’s also nifty feature that’s new in VS2017 and it makes working with analyzers more enjoyable. Not only does it allow me to fix a problem I’m currently looking at, but I can also fix that same problem Document, Project or Solution wide. Very nice.
And as you can see below, there’s also options to suppress rules. You can do this inline or in a global suppression file which it creates for you.
#pragma directive also has a description alongside it as a comment, which might be helpful for another developer. Usually I need to look up pragma codes so this is a nice VS feature which improves the overall developer experience.
Another feature I really like is that the warnings give you a short paragraph which explains the reasoning behind the rule violation. This particular warning is something which really resonates with me as I don’t like commented-out code. Dead code should be deleted. If there’s a chance you think you’ll need it later then no problem, that’s what source control is for!
If you need a full listing of rules I found the online help useful as you can filter by various rule types with tags.
Keeping in-line with the way Code Analysis for VS works, you can access the rule listing by right clicking on the Analyzers node inVS and selecting Open Active Rule Set.
From there the rule set is just another category node. If you’d like more information on customising rule sets I have a blog post on Visual Studio Code Analysis which goes over it in more depth.
A gotcha to be aware of
I could not get the rules to run on build and kept getting this error.
Warning CA0064 : No analysis was performed because the specified rule set could not be loaded or did not contain any managed code analysis rules.
I did post a question on the SonarLint Google Group, but as far as I could tell it was isolated to my machine. If this happens you’ll need to add the Analyzer assembly SonarAnalyzer.CSharp.dll as shown below.
If you’d like the analysis to run on build, enable the analysis on a per project basis by going to project properties and clicking “Enable Code Analysis on Build”.
The other way is to manually trigger analysis.
Features that stand out
These are the features which enjoyed the most while using this tool and will probably be a reason I’ll keep using it.
- Contains different rules to Microsoft’s built in analyzers and ReSharpers code suggestions which don’t clash. For me these rules were a little more practical. I’ll give some examples below.
- Warnings not only have a short description but have a long description with the reasoning behind the rule right in the IDE. Most other tools I’ve used link to a webpage.
- Rules are configured using the same system as VS built in Code Analysis and stored in
As I mentioned in the first bullet point, the rules and suggestion offered by SonarLint seem a little more useful. The rules are things I find myself fixing more often compared to the Code Analysis rules that come with VS or ReSharper. Although I have a feeling that might be due to the code base I’m using. I’ll know more as I use the tool over time with different projects.
Some examples of useful rules:
Nested control flow statements (spaghetti code)
Roslyn being open source has opened the door to more static analysis tools, a move which will ultimately improve the quality of all code bases written in Roslyn based .NET languages.
One last thing. I didn’t set this up but there is integration with the SonarQube system for detailed reporting of overall code-base health. So really, I’ve only just scratched the surface of the overall ecosystem. More tools I need to evaluate.