Sometime ago I was contacted by Patrick Smacchia, who is CEO and a lead developer in NDepend. In one sentence, NDepend is a tool that analyses your code and tells what is wrong and can be improved to avoid technical debt. Patrick offered my a free pro license for NDepend. A few years ago I was using it so it was an interesting proposition. We agreed that if I find NDepend useful, I will write a post about it and share my experience. As for me it's a win-win situation.
So far I used NDepend in 2 projects. The first one is a new project that I've started recently. The second one is a code written by someone else but I was asked to make an audit of it. I'm still not an expert of NDepend, nonetheless I have some thoughts to share with you. At the same time this is not a tutorial how to use NDepend. If you need one go for example here.
Case 1
When I started NDepend for the first time, after a long brake, I was a little but overwhelmed by the number of available options. However, quite quickly I learned how to use it. The first thing that struck me was the number of code smells detected by NDepend in my new project. I and my college spare no pains to write high quality code and despite that there are many things to improve. I think that when you work with some code for a while, you simply start to ignore some issues like too long methods, too big classes, methods with too many parameters. You need someone or something that will point you what is wrong. NDepend is good in doing that.
NDepend detects issues based on the rules. These rules are defined in so called Code Query LINQ which seems to be powerful. If you are familiar with "normal" LINQ, rules should be easy to understand and modify for you. I haven't tried yet but it also seems to be a great extension point and if you want you can define your own rules. It's worth mentioning that not every rule was obvious to me so it was very helpful that each rule has a description and an explanation how to fix it. If you don't see it, just click View Description button. Initially, I missed this button and I was annoyed that I don't understand everything. For guys like me, in the version of 2017.3 of NDepend team will introduce a few guided tour tooltips like the one below:
I also like that NDepend tracks changes from analysis to analysis. Thanks to that you can observe trends i.e. how many issues have been added/fixed since the last analysis. Really useful!
They are also little things that make you happy. For example, NDepend doesn't analyse directly the source code but assemblies. So, it's nice that we're informed that the source code is out of sync with PDB files. It can happen easily if you switch from branch to branch in Git. What is natural NDepend integrates with Visual Studio but you can also use its standalone version.
Suggestions
What would I improve? There are some minor things. When you start a new analyses, by default NDepend will analyse all the projects in the solution, including unit tests, acceptance tests etc. I think that they should be excluded from analysis by default. Of course you can exclude them manually or use the filter function (see the screenshot below) but it's easy to forget.
I also noticed that NDepend reports SpecFlow *.feature files as having invalid extension. I also miss an easy option to ignore/suppress some warnings reported by NDepend. I know that I can potentially modify a definition of a rule but it's not a perfect solution for me. According to Patrick, the next year SuppressWarning attribute will be supported by NDepend what should help.
NDepend has a rule Avoid methods with too many parameters and I agree that methods should not have too many parameters. However, if we use dependency injections it is quite common that constructors have more parameters than usually. In this case they should not be reported. Here also NDepend team thinks what to do.
This one is not an issue but feature request. I know that NDepend is focused on analysing the code. However, if it's able to detect so many issues, it will be great to provide an option to automatically or semi-automatically fix and refactor them. Of course, it's something completely new, but would be an amazing function ;)
Case 2
When I got some experience with NDepend, I decided to use it to make an audit. Firstly, I roughly analysed the code on my own and then I ask NDepend to do it again. Thanks to that I found a few more problems e.g.:
Suggestions
I have one suggestion as to Search View. In order to see issues found for a given element you need to select it, open the context menu and then click Select issues.... A little bit cumbersome. I would like to see issues when hovering a mouse over found elements. For example in a tooltip. As far as I know it'll be improved in 2018.
I didn't find the rule Avoid having different types with same name very useful. It reports classes like Startup, SwaggerConfig... which probably have such names in any project around all the world :) The good information is that it should be changed in the next version of NDepend. Besides, I found manually a few cases where disposable (instances of DirectorySearcher and DirectoryEntry) resources were not disposed. NDepend doesn't detect this issues. However, I think that it's feasible. Patrick says that it's something that definitely will be investigated.
The source code analysed by me contained a lot of magic strings in the code. Many of them were duplicated multiple times. However, I didn't find any rule that was violated by this. I think that there should be a rule suggesting to move this strings to const fields or to introduce static class to store these strings or to move them to resources. Patrick pointed that currently NDepend warns about public const magic strings but so far it's not aware of string values (this will come but later).
Last but not least the navigation function i.e. Navigate forward and Navigate backward buttons will be useful. It's quite easy to get lost when you are analysing results within Visual Studio or in the standalone NDepend. For me it is intuitive to press Navigate forward button a few times. Of course, if you are analysing the generated report (which is collection of HTML sites), the browser supports navigation.
Summary
Without any hesitation I can recommend NDepend. Despite some issues it's very helpful and I think that it can really help keeping your code clean. Besides, many of these issues are in fact minor and will be fixed soon. I also appreciate the contact with Patrick. If you have any problems with NDepend, I'm pretty sure that he or his team will respond quickly. I know that because I checked.
So far I used NDepend in 2 projects. The first one is a new project that I've started recently. The second one is a code written by someone else but I was asked to make an audit of it. I'm still not an expert of NDepend, nonetheless I have some thoughts to share with you. At the same time this is not a tutorial how to use NDepend. If you need one go for example here.
Case 1
When I started NDepend for the first time, after a long brake, I was a little but overwhelmed by the number of available options. However, quite quickly I learned how to use it. The first thing that struck me was the number of code smells detected by NDepend in my new project. I and my college spare no pains to write high quality code and despite that there are many things to improve. I think that when you work with some code for a while, you simply start to ignore some issues like too long methods, too big classes, methods with too many parameters. You need someone or something that will point you what is wrong. NDepend is good in doing that.
NDepend detects issues based on the rules. These rules are defined in so called Code Query LINQ which seems to be powerful. If you are familiar with "normal" LINQ, rules should be easy to understand and modify for you. I haven't tried yet but it also seems to be a great extension point and if you want you can define your own rules. It's worth mentioning that not every rule was obvious to me so it was very helpful that each rule has a description and an explanation how to fix it. If you don't see it, just click View Description button. Initially, I missed this button and I was annoyed that I don't understand everything. For guys like me, in the version of 2017.3 of NDepend team will introduce a few guided tour tooltips like the one below:
I also like that NDepend tracks changes from analysis to analysis. Thanks to that you can observe trends i.e. how many issues have been added/fixed since the last analysis. Really useful!
They are also little things that make you happy. For example, NDepend doesn't analyse directly the source code but assemblies. So, it's nice that we're informed that the source code is out of sync with PDB files. It can happen easily if you switch from branch to branch in Git. What is natural NDepend integrates with Visual Studio but you can also use its standalone version.
Suggestions
What would I improve? There are some minor things. When you start a new analyses, by default NDepend will analyse all the projects in the solution, including unit tests, acceptance tests etc. I think that they should be excluded from analysis by default. Of course you can exclude them manually or use the filter function (see the screenshot below) but it's easy to forget.
I also noticed that NDepend reports SpecFlow *.feature files as having invalid extension. I also miss an easy option to ignore/suppress some warnings reported by NDepend. I know that I can potentially modify a definition of a rule but it's not a perfect solution for me. According to Patrick, the next year SuppressWarning attribute will be supported by NDepend what should help.
NDepend has a rule Avoid methods with too many parameters and I agree that methods should not have too many parameters. However, if we use dependency injections it is quite common that constructors have more parameters than usually. In this case they should not be reported. Here also NDepend team thinks what to do.
This one is not an issue but feature request. I know that NDepend is focused on analysing the code. However, if it's able to detect so many issues, it will be great to provide an option to automatically or semi-automatically fix and refactor them. Of course, it's something completely new, but would be an amazing function ;)
Case 2
When I got some experience with NDepend, I decided to use it to make an audit. Firstly, I roughly analysed the code on my own and then I ask NDepend to do it again. Thanks to that I found a few more problems e.g.:
- There were 4 places in the code where Thread.Sleep was used. Usually it means some threading problems.
- One class with public fields was found.
- The namespaces were not consistent with the structure of folders.
- Some very long methods were found.
- ...
Suggestions
I have one suggestion as to Search View. In order to see issues found for a given element you need to select it, open the context menu and then click Select issues.... A little bit cumbersome. I would like to see issues when hovering a mouse over found elements. For example in a tooltip. As far as I know it'll be improved in 2018.
I didn't find the rule Avoid having different types with same name very useful. It reports classes like Startup, SwaggerConfig... which probably have such names in any project around all the world :) The good information is that it should be changed in the next version of NDepend. Besides, I found manually a few cases where disposable (instances of DirectorySearcher and DirectoryEntry) resources were not disposed. NDepend doesn't detect this issues. However, I think that it's feasible. Patrick says that it's something that definitely will be investigated.
The source code analysed by me contained a lot of magic strings in the code. Many of them were duplicated multiple times. However, I didn't find any rule that was violated by this. I think that there should be a rule suggesting to move this strings to const fields or to introduce static class to store these strings or to move them to resources. Patrick pointed that currently NDepend warns about public const magic strings but so far it's not aware of string values (this will come but later).
Last but not least the navigation function i.e. Navigate forward and Navigate backward buttons will be useful. It's quite easy to get lost when you are analysing results within Visual Studio or in the standalone NDepend. For me it is intuitive to press Navigate forward button a few times. Of course, if you are analysing the generated report (which is collection of HTML sites), the browser supports navigation.
Summary
Without any hesitation I can recommend NDepend. Despite some issues it's very helpful and I think that it can really help keeping your code clean. Besides, many of these issues are in fact minor and will be fixed soon. I also appreciate the contact with Patrick. If you have any problems with NDepend, I'm pretty sure that he or his team will respond quickly. I know that because I checked.
orcid.org/0000-0002-6838-2135
0 comments:
Post a Comment