Overview of new features in NDepend 6
What is NDepend has already been discussed in Habré - this is a static code analyzer on .NET. Recently a new version has been released - the 6th version of this wonderful utility, about which new features are described below. This is a translation, the original article is here .
Recently released NDepend 6 . Until now, the release of major releases was scheduled for a while after the release of Visual Studio, and now Visual Studio 2015 is in the pre-release state. NDepend 6 is the result of hard work for 18 months. After 11 years of development, NDepend has reached a certain level of maturity, but there are still many possibilities and improvements that can be made. And for version 6, the most sensitive issue was the choice of new features and improvements for users. Since version 5 was released in 2013, ideas have been received with Visual Studio User Voices and NDepend User Voices . As a matter of fact, the new features of the 6th version well reflect the most requested features that have been completed.
Users asked for greater integration of NDepend into the auto build process. They ran NDepend.Console.exe to collect information and report on whether the important rules that the build process is considered unsuccessful are violated (this information can be obtained by return code from NDepend.Console.exe). Users requested to show more information directly in the build tools. There are many build technologies, the most requested of which are TFS , TeamCity and SonarQube . As a result, the developers collaborated with the high-class experts of these technologies to make embedded integration, which presumably includes the majority of usage scenarios, and which will be supported for future versions and receive new features.
Since Since users wanted more integration with the build process, over the past year, efforts have mostly been focused on tools for Visual Studio. NDepend was integrated into Visual Studio using VS Addin technology - this decision was made by the development team in 2009. At that time, VSIX (another stop of developing extensions for the studio) was raw, and VS2008 and VS2005 also had to be supported, so VS Addin was the right choice. Over the years, VS Addin has become less and less relevant, has not received improvements from Microsoft, and led to crashes, but most importantly, it was not possible to remember the location of the NDepend windows during execution. This gave users great inconvenience and ended with requests for User Voice to remember the location of the windows .
')
Starting with version 6, NDepend is based on VSIX technology for integration into VS 2015, 2013, 2012 and 2010. In addition, Microsoft has banned the use of VS Addin in 2015 studios. In any case, thanks to VSIX, it became possible to make a more smooth and reliable integration with Visual Studio, with remembering windows, new features (for example, attaching the NDepend project to .suo (and not just to .sln), and full support for hot keys).
Also, there were three features provided by free studio extensions that were included in NDepend so that they were always at hand.
Rules for .NET code are the main features of NDepend. Users have left a lot of feedback on how to improve existing rules, mostly to reduce false positives. Therefore, about a third of the default rules were redone in accordance with their recommendations.
It's great that the code rules are mutable C # LINQ requests that contain few comments. But for many users, they were not informative enough about why the rule creates a warning, why compliance with a particular rule will improve the code, and how to fix a violation of the rule. Therefore, the ability to add 2 formatted text to the source code of the NDepend rule through the
Another user need was to make the rules available between several NDepend projects. Typically, a company has several projects analyzed with NDepend, and users want to manage them all at once. And taking into account that on NDepend it is easier to write your own rules for .NET code than anywhere else, users wanted the ability to use one profile for different projects. Therefore, in NDepend 6 it is possible to define a list of rules that can be used together in NDepend projects.
In NDepend, the visualization of code metrics using treemap was already done , and it was decided to add a coloring. The idea is that you can show two code metrics. One is represented by a rectangular area, and the other by the color of the rectangle. For example, the following picture shows the coverage of the NDepend code with 6 tests in a specific but convenient and accurate way.
Having looked, it is immediately clear that a colored treemap can help to understand information that would be difficult to understand in another way. Despite the fact that the NDepend code is covered with tests for 82%, you can see clusters of red rectangles that show code that is not sufficiently covered with tests. Probably there is no longer a tool that can show it with such precision.
NDepend developers are trying to make product capabilities coherent. Therefore, you can visualize not only any two of the many NDepend'a metrics , but also your own code metrics, described via LINQ queries in C # , and you can also highlight the final code of the rule or query. As a result, if you request complex methods, you can display them on a color treemap:
It is worth noting that code coverage with tests is one of the most important quality indicators, a separate interface was also added for this in the results of the query code:
The product is in a constantly changing environment. This means that some features that work well before should be revised. Some of these needed improvements were made in NDepend version 6.
Supporting code generated by the C # and VB.NET compiler: More and more sugar appeared from version to version in C # and VB.NET. It started with anonymous methods and iterators in C # 2.0. Then came the lambdas and anonymous types in C # 3.0, and then async / await in C # 5.0. These constructs force the compiler to generate additional methods and types. And since these constructs are quite often used, these generated elements accumulate in the IL code. And NDepend mainly relies on IL code to get information about the code . Therefore, the NDepend code model includes all the generated methods and types, and this annoys the user, who is mostly interested only in his code. Now NDepend fixes this. Just getting rid of all these generated elements is not an option, because they actually contain some custom code. Therefore, some heuristics have been developed to combine these generated elements with custom classes and methods that contain the code for which it is generated by the compiler. Thus, there was no need to compromise - all code model data was saved, including code metrics (number of lines, percentage of coverage, cyclomatic complexity, ...), dependencies, and differences.
Improved async support: Asynchronous constructs have specificity, which caused some difficulties with NDepend. Custom code, in fact, is embedded by the compiler in the generated method, which overrides the virtual method IAsyncStateMachine.MoveNext () . Therefore, the IL code that calls this generated MoveNext () method is associated with the abstract interface method, and not with the implementation. Calls to the asynchronous method are lost in the IL code ... and, therefore, in the NDepend code model. Thanks to the heuristics written for the preceding paragraph, NDepend is now able to analyze and identify the correct calling asynchronous methods.
High-resolution support: Now high-resolution monitors (such as 4K) are becoming available and, as a result, more and more developers are working with the appropriate Windows settings. This means that the pixel density is higher and, therefore, more pixels are used to display the graphic element (text, picture). NDepend's interface is mainly based on the Windows Form and GDI +, and these technologies by default do not scale well when Windows is configured for high resolution. When users started reporting this problem, it was decided to remake the entire NDepend interface so that it could work with resolution settings from 100% to 250%. It was an opportunity to improve some graphical elements and learn some ways to work with Windows Form and GDI + at high resolution. The results of this will be described in a future article on the NDepend blog, because On the Internet, it is clear that this is a problem for many developers.
Topics in Visual Studio: Statistics show that most users use NDepend from Visual Studio. Therefore, the themes of the NDepend interface are not very well combined with standard Visual Studio themes, such as Light, Dark, Blue, and VS2010 Standard Theme. Fortunately, in NDepend menu items, panels, bindings ... are based on the DevExpress WinForm library and their latest version includes these themes (and not only). Therefore, a simple update to the latest version helped.
Analysis Improvement: Some improvements should have been made regarding the analysis. The NDepend project references some directories and assembly names (without a file extension). During the analysis, the location of the assemblies for analysis was in the following two ways. If many copies of the assembly are found, then if they are all the same, then NDepend took one of them, and if they were different, then NDepend reported an error, because This situation is considered a serious problem of deploying a solution. But over time, new technologies, such as Windows Phone or Portable Class Libraries, appeared, and they led to this situation during proper operation. Therefore, when such a situation is detected, NDepend 6 now uses heuristic analysis to find the correct build based on its version, dependencies, and file size.
The right choice of new features
Recently released NDepend 6 . Until now, the release of major releases was scheduled for a while after the release of Visual Studio, and now Visual Studio 2015 is in the pre-release state. NDepend 6 is the result of hard work for 18 months. After 11 years of development, NDepend has reached a certain level of maturity, but there are still many possibilities and improvements that can be made. And for version 6, the most sensitive issue was the choice of new features and improvements for users. Since version 5 was released in 2013, ideas have been received with Visual Studio User Voices and NDepend User Voices . As a matter of fact, the new features of the 6th version well reflect the most requested features that have been completed.
Integration into the assembly process
Users asked for greater integration of NDepend into the auto build process. They ran NDepend.Console.exe to collect information and report on whether the important rules that the build process is considered unsuccessful are violated (this information can be obtained by return code from NDepend.Console.exe). Users requested to show more information directly in the build tools. There are many build technologies, the most requested of which are TFS , TeamCity and SonarQube . As a result, the developers collaborated with the high-class experts of these technologies to make embedded integration, which presumably includes the majority of usage scenarios, and which will be supported for future versions and receive new features.
Improved integration with Visual Studio
Since Since users wanted more integration with the build process, over the past year, efforts have mostly been focused on tools for Visual Studio. NDepend was integrated into Visual Studio using VS Addin technology - this decision was made by the development team in 2009. At that time, VSIX (another stop of developing extensions for the studio) was raw, and VS2008 and VS2005 also had to be supported, so VS Addin was the right choice. Over the years, VS Addin has become less and less relevant, has not received improvements from Microsoft, and led to crashes, but most importantly, it was not possible to remember the location of the NDepend windows during execution. This gave users great inconvenience and ended with requests for User Voice to remember the location of the windows .
')
Starting with version 6, NDepend is based on VSIX technology for integration into VS 2015, 2013, 2012 and 2010. In addition, Microsoft has banned the use of VS Addin in 2015 studios. In any case, thanks to VSIX, it became possible to make a more smooth and reliable integration with Visual Studio, with remembering windows, new features (for example, attaching the NDepend project to .suo (and not just to .sln), and full support for hot keys).
Also, there were three features provided by free studio extensions that were included in NDepend so that they were always at hand.
Rule improvements
Rules for .NET code are the main features of NDepend. Users have left a lot of feedback on how to improve existing rules, mostly to reduce false positives. Therefore, about a third of the default rules were redone in accordance with their recommendations.
It's great that the code rules are mutable C # LINQ requests that contain few comments. But for many users, they were not informative enough about why the rule creates a warning, why compliance with a particular rule will improve the code, and how to fix a violation of the rule. Therefore, the ability to add 2 formatted text to the source code of the NDepend rule through the
<Description> and <HowToFix> . This is a good opportunity to describe each rule by default and explain it in more detail to the user. Both in the interface and in the report the user can choose what to watch - Description / HowToFix or the source code of the rule in C # LINQ.Another user need was to make the rules available between several NDepend projects. Typically, a company has several projects analyzed with NDepend, and users want to manage them all at once. And taking into account that on NDepend it is easier to write your own rules for .NET code than anywhere else, users wanted the ability to use one profile for different projects. Therefore, in NDepend 6 it is possible to define a list of rules that can be used together in NDepend projects.
Visualization of code metrics
In NDepend, the visualization of code metrics using treemap was already done , and it was decided to add a coloring. The idea is that you can show two code metrics. One is represented by a rectangular area, and the other by the color of the rectangle. For example, the following picture shows the coverage of the NDepend code with 6 tests in a specific but convenient and accurate way.
- Rectangles are methods
- Rectangular areas are proportional to the number of lines of code,
- The color of the rectangle - the percentage of code coverage tests.
Having looked, it is immediately clear that a colored treemap can help to understand information that would be difficult to understand in another way. Despite the fact that the NDepend code is covered with tests for 82%, you can see clusters of red rectangles that show code that is not sufficiently covered with tests. Probably there is no longer a tool that can show it with such precision.
NDepend developers are trying to make product capabilities coherent. Therefore, you can visualize not only any two of the many NDepend'a metrics , but also your own code metrics, described via LINQ queries in C # , and you can also highlight the final code of the rule or query. As a result, if you request complex methods, you can display them on a color treemap:
It is worth noting that code coverage with tests is one of the most important quality indicators, a separate interface was also added for this in the results of the query code:
What else had to be done
The product is in a constantly changing environment. This means that some features that work well before should be revised. Some of these needed improvements were made in NDepend version 6.
Supporting code generated by the C # and VB.NET compiler: More and more sugar appeared from version to version in C # and VB.NET. It started with anonymous methods and iterators in C # 2.0. Then came the lambdas and anonymous types in C # 3.0, and then async / await in C # 5.0. These constructs force the compiler to generate additional methods and types. And since these constructs are quite often used, these generated elements accumulate in the IL code. And NDepend mainly relies on IL code to get information about the code . Therefore, the NDepend code model includes all the generated methods and types, and this annoys the user, who is mostly interested only in his code. Now NDepend fixes this. Just getting rid of all these generated elements is not an option, because they actually contain some custom code. Therefore, some heuristics have been developed to combine these generated elements with custom classes and methods that contain the code for which it is generated by the compiler. Thus, there was no need to compromise - all code model data was saved, including code metrics (number of lines, percentage of coverage, cyclomatic complexity, ...), dependencies, and differences.
Improved async support: Asynchronous constructs have specificity, which caused some difficulties with NDepend. Custom code, in fact, is embedded by the compiler in the generated method, which overrides the virtual method IAsyncStateMachine.MoveNext () . Therefore, the IL code that calls this generated MoveNext () method is associated with the abstract interface method, and not with the implementation. Calls to the asynchronous method are lost in the IL code ... and, therefore, in the NDepend code model. Thanks to the heuristics written for the preceding paragraph, NDepend is now able to analyze and identify the correct calling asynchronous methods.
High-resolution support: Now high-resolution monitors (such as 4K) are becoming available and, as a result, more and more developers are working with the appropriate Windows settings. This means that the pixel density is higher and, therefore, more pixels are used to display the graphic element (text, picture). NDepend's interface is mainly based on the Windows Form and GDI +, and these technologies by default do not scale well when Windows is configured for high resolution. When users started reporting this problem, it was decided to remake the entire NDepend interface so that it could work with resolution settings from 100% to 250%. It was an opportunity to improve some graphical elements and learn some ways to work with Windows Form and GDI + at high resolution. The results of this will be described in a future article on the NDepend blog, because On the Internet, it is clear that this is a problem for many developers.
Topics in Visual Studio: Statistics show that most users use NDepend from Visual Studio. Therefore, the themes of the NDepend interface are not very well combined with standard Visual Studio themes, such as Light, Dark, Blue, and VS2010 Standard Theme. Fortunately, in NDepend menu items, panels, bindings ... are based on the DevExpress WinForm library and their latest version includes these themes (and not only). Therefore, a simple update to the latest version helped.
Analysis Improvement: Some improvements should have been made regarding the analysis. The NDepend project references some directories and assembly names (without a file extension). During the analysis, the location of the assemblies for analysis was in the following two ways. If many copies of the assembly are found, then if they are all the same, then NDepend took one of them, and if they were different, then NDepend reported an error, because This situation is considered a serious problem of deploying a solution. But over time, new technologies, such as Windows Phone or Portable Class Libraries, appeared, and they led to this situation during proper operation. Therefore, when such a situation is detected, NDepend 6 now uses heuristic analysis to find the correct build based on its version, dependencies, and file size.
Source: https://habr.com/ru/post/261265/
All Articles