CodeRush for Roslyn: Part 2 - feature overview for better code
We are releasing a new product - CodeRush for Roslyn (hereinafter CRR ).
The first part was about the Unit Test Runner, and in this article we will discuss the features of CRR, which help to improve the quality of the code:
All the examples in the article are made in Visual Studio 2015 on the source code of the OpenCover project.
')
Visual Studio checks the code when typing. For example, for this code snippet, the warning The variable'testValiable 'is shown but never used (CS0168) appears in the Error List.
In Visual Studio 2015, the formation of such errors is implemented in special classes called Roslyn Code Analyzer . Code Analyzer is, to put it simply, part of the implementation of the Visitor pattern for Roslyn Syntax Tree. But if you search in MSDN by error code CS0168 , there is this article , in it CS0168 is called “Compiler Warning”, and not Analyzer or Diagnostic , as is customary in Roslyn. This is due to the fact that CS0168 appeared at the time when Roslyn was not yet used in Visual Studio, and this error was detected at the stage of partial compilation of the code. We will not go further into the details, but it is useful to know that in Visual Studio 2015 almost all the messages in the Error List are generated using Roslyn Code Analyzers . Read more about them here . A full list of standard diagnostics for .NET can be found here . CRR adds the following diagnostics to this set:
This screenshot is made from the standard studio ruleset editor, i.e. if you are using a studio code analyzer, just add the CRR diagnostics to your ruleset.
Check the OpenCover project using standard Visual Studio diagnostics. To do this, open the properties of the solution and set the settings as shown in the picture.
And, as a result, we get about a thousand messages in the Error List.
Thousands of messages are not the limit, because not the largest set of diagnostics was used. However, it is not the number of diagnostics that is important, but their quality. To attract the attention of the developer is only when it is really necessary.
Let's try to analyze OpenCover using our diagnostics. There are three ways to do this:
If the project is large, static analysis in the background may interfere with the normal operation of Visual Studio. This is due to the fact that diagnostics expand syntactic trees, and in some situations this leads to significant memory consumption. After checking, full syntax trees are no longer needed, and memory is released. But this creates memory traffic, and leads to the fact that most of the computing resources will be spent on garbage collection. Manual scan mode will make predictable moments when Visual Studio is slow. To run a static analysis in this mode, you need to click on the Refresh button in the Code Issues window (the Refresh button is the first on the left).
Also, manual start of diagnostics is provided in the Visual Studio interface . But in this case, you will have to add the CRR diagnostics to the ruleset as described here .
Visual Studio has a standard mechanism for performing static code analysis in the background. This mechanism is described here . As already mentioned, checking in the background on large projects can cause studio freezes. Turn with caution. In order for CRR diagnostics to be performed in this mode, you must set the Include CodeRush diagnostics option into the VisualStudio background analysis .
CRR has an executable file that can be run from the command line on the developer’s machine or on the build server. The file is called DevExpress.StaticCodeAnalysis.exe . You can find it in the plugin directory (you can open it from CodeRush | Support | Extension Folder ... ). The file is a fully autonomous console version of CRR diagnostics. No additional files are required for its operation. Because of this, it is easily integrated into any assembly system. Just copy DevExpress.StaticCodeAnalysis.exe to the build server and enter a simple call into the build script:
As a result, a results report will be generated in the results.txt .
We do not pursue a number of diagnostics, but only implement really useful ones, paying a lot of attention to false positives. The result of the OpenCover source check is shown below.
There were only a couple of strange places:
In this section of the diagnostic code, it is found that CurrentCulture and CurrentUICulture are assigned twice. Diagnostics worked correctly, but apparently, this is done in order to get the text exception in English.
The second strange place was found in the tests.
The result variable is assigned twice. Diagnostics worked correctly, although the author of the test in the comments wrote that it was intended. Excellent result - no false positives.
In CRR, naming and spell checking are also implemented as Roslyn Code Analyzer . These checks are disabled by default because configuration is required before using them. For example, if you enable without configuration on an OpenCover project, there will be a huge number of naming rule violation messages in the Error List. To configure the naming rules there is a page in Options . You can enable and configure naming checks for types, namespaces, properties, and so on.
The spell checker is implemented on the DevExpress Spellchecker core . Typos go to the Error List, and are also highlighted in the code by a wavy line. In the context menu, spellchecker creates a list of proposed replacements.
In addition to diagnostics, there is another way to improve your code. This is code coverage tests. In the previous article there was an overview of the capabilities of our Test Runner , but we didn’t tell about the launch of tests with coverage analysis. In Test Runner there is a test run mode in which the code is instrumented. In this mode, the test run takes a longer time, so separate buttons are provided for running tests with coverage analysis.
Coverage can be viewed in the Code Coverage Tool Window . In this screenshot, you can see that the conditions branch in the second cycle is not covered by the else link.
According to the analysis of coverage, new tests are usually written that increase the percentage of coverage. It should be remembered that 100% code coverage of tests does not guarantee the absence of problems in it. For example, this code snippet has a high percentage of coverage.
But among the tests there is no one that checks conditional branching when the condition is triggered.
And if the coverage was considered not by operators, but by the branches of conditional operators, then the figure would be different.
CodeRush for Roslyn is a new handy tool that helps to write the correct code and fix problems in the existing one. You can download it in the Visual Studio Gallery .
In the next part , consider the possibilities of CRR to navigate through the code.
The first part was about the Unit Test Runner, and in this article we will discuss the features of CRR, which help to improve the quality of the code:
- Static Analysis (Static Analysis).
- Spell Checker (Spell Checker).
- Naming Conventions (Naming Conventions).
- Analysis of code coverage by tests (Test Coverage).
All the examples in the article are made in Visual Studio 2015 on the source code of the OpenCover project.
')
Static analysis
Visual Studio checks the code when typing. For example, for this code snippet, the warning The variable'testValiable 'is shown but never used (CS0168) appears in the Error List.
In Visual Studio 2015, the formation of such errors is implemented in special classes called Roslyn Code Analyzer . Code Analyzer is, to put it simply, part of the implementation of the Visitor pattern for Roslyn Syntax Tree. But if you search in MSDN by error code CS0168 , there is this article , in it CS0168 is called “Compiler Warning”, and not Analyzer or Diagnostic , as is customary in Roslyn. This is due to the fact that CS0168 appeared at the time when Roslyn was not yet used in Visual Studio, and this error was detected at the stage of partial compilation of the code. We will not go further into the details, but it is useful to know that in Visual Studio 2015 almost all the messages in the Error List are generated using Roslyn Code Analyzers . Read more about them here . A full list of standard diagnostics for .NET can be found here . CRR adds the following diagnostics to this set:
This screenshot is made from the standard studio ruleset editor, i.e. if you are using a studio code analyzer, just add the CRR diagnostics to your ruleset.
Check the OpenCover project using standard Visual Studio diagnostics. To do this, open the properties of the solution and set the settings as shown in the picture.
And, as a result, we get about a thousand messages in the Error List.
Thousands of messages are not the limit, because not the largest set of diagnostics was used. However, it is not the number of diagnostics that is important, but their quality. To attract the attention of the developer is only when it is really necessary.
Let's try to analyze OpenCover using our diagnostics. There are three ways to do this:
- Start the scan manually.
- Check in background.
- Check from the console.
Manual scan run
If the project is large, static analysis in the background may interfere with the normal operation of Visual Studio. This is due to the fact that diagnostics expand syntactic trees, and in some situations this leads to significant memory consumption. After checking, full syntax trees are no longer needed, and memory is released. But this creates memory traffic, and leads to the fact that most of the computing resources will be spent on garbage collection. Manual scan mode will make predictable moments when Visual Studio is slow. To run a static analysis in this mode, you need to click on the Refresh button in the Code Issues window (the Refresh button is the first on the left).
Also, manual start of diagnostics is provided in the Visual Studio interface . But in this case, you will have to add the CRR diagnostics to the ruleset as described here .
Background check
Visual Studio has a standard mechanism for performing static code analysis in the background. This mechanism is described here . As already mentioned, checking in the background on large projects can cause studio freezes. Turn with caution. In order for CRR diagnostics to be performed in this mode, you must set the Include CodeRush diagnostics option into the VisualStudio background analysis .
Check from console
CRR has an executable file that can be run from the command line on the developer’s machine or on the build server. The file is called DevExpress.StaticCodeAnalysis.exe . You can find it in the plugin directory (you can open it from CodeRush | Support | Extension Folder ... ). The file is a fully autonomous console version of CRR diagnostics. No additional files are required for its operation. Because of this, it is easily integrated into any assembly system. Just copy DevExpress.StaticCodeAnalysis.exe to the build server and enter a simple call into the build script:
DevExpress.StaticCodeAnalysis.exe EditorsDemos\EditorsSamples_CS.sln results.txt
As a result, a results report will be generated in the results.txt .
Test results
We do not pursue a number of diagnostics, but only implement really useful ones, paying a lot of attention to false positives. The result of the OpenCover source check is shown below.
There were only a couple of strange places:
In this section of the diagnostic code, it is found that CurrentCulture and CurrentUICulture are assigned twice. Diagnostics worked correctly, but apparently, this is done in order to get the text exception in English.
The second strange place was found in the tests.
The result variable is assigned twice. Diagnostics worked correctly, although the author of the test in the comments wrote that it was intended. Excellent result - no false positives.
Checking naming and typos in titles
In CRR, naming and spell checking are also implemented as Roslyn Code Analyzer . These checks are disabled by default because configuration is required before using them. For example, if you enable without configuration on an OpenCover project, there will be a huge number of naming rule violation messages in the Error List. To configure the naming rules there is a page in Options . You can enable and configure naming checks for types, namespaces, properties, and so on.
The spell checker is implemented on the DevExpress Spellchecker core . Typos go to the Error List, and are also highlighted in the code by a wavy line. In the context menu, spellchecker creates a list of proposed replacements.
Checking code coverage tests
In addition to diagnostics, there is another way to improve your code. This is code coverage tests. In the previous article there was an overview of the capabilities of our Test Runner , but we didn’t tell about the launch of tests with coverage analysis. In Test Runner there is a test run mode in which the code is instrumented. In this mode, the test run takes a longer time, so separate buttons are provided for running tests with coverage analysis.
Coverage can be viewed in the Code Coverage Tool Window . In this screenshot, you can see that the conditions branch in the second cycle is not covered by the else link.
According to the analysis of coverage, new tests are usually written that increase the percentage of coverage. It should be remembered that 100% code coverage of tests does not guarantee the absence of problems in it. For example, this code snippet has a high percentage of coverage.
But among the tests there is no one that checks conditional branching when the condition is triggered.
if(_domain == null) return;
And if the coverage was considered not by operators, but by the branches of conditional operators, then the figure would be different.
CodeRush for Roslyn is a new handy tool that helps to write the correct code and fix problems in the existing one. You can download it in the Visual Studio Gallery .
In the next part , consider the possibilities of CRR to navigate through the code.
Source: https://habr.com/ru/post/303376/
All Articles