Roslyn analyzers: habits and habitats

The other day I explained to one friend what Roslyn analyzers are and how to write them. The answer turned out to be massive, and I decided to put it in a separate publication.

What are Roslyn analyzers? In short, this is a great way to write refactorings like the Resharper ones. Do you constantly encounter the same mistake in the review process? Write an analyzer with a fixer and forget about this error. The technical side is quite simple, this article , this video , this series of posts , and this tutorial are perfect for an initial acquaintance. I will try to describe the rake moments that personally caused me difficulty.

The first is Syntax Vizualizer. Any parser contains parsing of the syntax tree. A typical task is to have a node and you need to find its ancestor with the type “class declaration”, or “find all the nodes of the method declaration that uses string literals”. The syntax tree can be with a dozen levels of nesting, and to analyze it, I would like to have visualization. Two popular tools: Syntax Vizualizer and LINQPad. The first goes by default, gives a ton of technical information on each node, and significantly slows down on my computer. Plus, when I type the analyzer code, the Syntax Vizualizer starts to visualize the directly printed code, which is confusing. LINQPad gives a little less information, but more beautiful and clearer, so I recommend.

The next moment is the tests. Without them, nowhere. In fact, there are two options for testing. First: write an analyzer, open a second studio copy, create a project with a written analyzer, connect from the first studio to the second process (Attach Process), start debug. The correct test version: open the test class, write the code that should be highlighted by the analyzer, add a test.
')
Also recommend the Test First approach. First, we write the wrong code, implement the analyzer. When the analyzer is ready - we write the test for fix, we think how to move from the initial state to the fixed state, we write the fix. Specifically, in the case of analyzers, such a step-by-step approach is excellent.

Ever heard of defensive programming? In analyzers, push it to all possible places, because the analyzer that has fallen off according to the NRE may not work until the studio is rebooted.

Consider, most analyzers are ruined by uselessness. When I first heard about analyzers, I wanted to write my own. Ideas arose constantly, but the implementation came out too complicated / costly. The first combat analyzer was written only six months after meeting Roslyn. The next one is in another three months. I can assume that when working with small projects (2 people in a team), the technology is not particularly useful - the tasks / technologies are typical, everything reasonable is already covered with R # or VS.

After the transition to a new project (6 people in a team), 3 suitable places for analysis were found almost immediately. Two were rejected by the team as unnecessary. Moral: consult with colleagues, they will be happy to explain why you do not need an analyzer and you do not have to waste time on useless work. By the way, my colleagues turned out to be my most professional customers - everything is explained clearly, on the fingers, with examples.

Managers sometimes require numbers: how much we spend, what we get. Here, the assessment is quite simple: development takes 2 days on a turnkey analyzer (with tests \ integration \ infrastructure). The developers of PVS-Studio mentioned that they can spend 2 weeks on one analyzer. Do not trust them , but they sell their analyzers. If you are sawing an analyzer for an internal project (and you have already written to write analyzers, at least for training) - 2 days should be enough. It is more difficult to estimate profit. A trivial case is a bug that regularly pops up on Code Review: someone LINQ uses in the kernel, someone serializes the date without specifying the format. Accordingly, the profit is calculated as the frequency of the error multiplied by the price of the fix multiplied by the year.

There are more original cases. For example, there is a service aggregating data from a dozen banks. Each bank has its own rules of comparison \ price rounding, each bank has its own price class, with a decimal caste. As soon as the developer deploit on the prod type comparison

return localBankPrice == centralBankPrice; 

the manager takes out two jars of vaseline from the safe. So, Roslyn is not the worst medicine for Vaseline Allergy.

In principle, analyzers can be useful in several other situations. Trivial - product for sale. More spells with writing, but (possible) profit is thicker. If you are interested in learning about industrial development, call pavsenin \ Irina_DevExpress (DevExpress) and Andrey2008 (PVS-Studio).

A slightly less trivial case is analyzers supplied with its own library, a sort of protection against incorrect use.

There are also comrades like eugenebb who create special plug-in magic , but this is a completely different story.

To summarize, analyzers are extremely interesting, especially if you do not pin great hopes on them. If you have a dozen free evenings for leisurely exploring something interesting - poke Roslyn.