In the previous post, I showed several ways a developer can statically suppress a DiagnosticAnalyzer. However, what if you need to suppress diagnostics only when a specific code condition is met? In Roslyn, this is exactly what a DiagnosticSuppressor enables. In this post, we will explore how conditional suppression works and why it can be a powerful tool in building smarter C# analyzers.
So far we looked into Diagnostic Analyzers and Code Actions from the perspective of a creator! What if we switch roles and take a look from the consumer's view point of those tools!
In the previous post in the Roslyn series we have explored how we could create code analyzers and how to test them, to reduce the cognitive load on our development team! However, what if we take an extra mile and create a Code Fix Provider to provide some suggestions for the developers! Shall we?
In the previous post we have seen how it is possible to create a diagnostic analyzer using Roslyn APIs. Being a TDD advocate it would be disappointing not to talk about how we could test our code analyzer! So let's take a look into it.
We are all familiar with diagnostics that are provided from the compiler when we develop an application, they could be in form of warnings, errors or code suggestions. A diagnostic or code analyzer, inspects our open files for various metrics, like style, maintainability, design, etc. However, sometimes we need to write a tailor-made analysis for our specific situation, tool, or project.