This is the second post related to the NDepend tool and Code Quality for .NET Core application I’m writing. I’m sure it will be many of them, because of how important is this subject, but let’s start with something.
If you want to know more about how to install the NDepend tool in Visual Studio, I recommend you to take a look at my first post about it clicking right:
https://medium.com/@alexandre.malavasi/code-quality-with-ndepend-tool-net-core-854ec070b47d
One of the hardest parts of quality for software projects is to define the code rules for the team, that everyone agrees based on their own experience and based on what the project needs. It does not matter if it is a junior or senior developer, everyone has an opinion, but there is a general agreement on the market about the majority of recommendation we could apply in our projects. Therefore, this post doesn’t have the purpose to define what code rules are recommendable, but the scope for this article is to demonstrate how we can set up the code rules decided by the team on the NDepend tool.
Once you have it installed, the code rules explorer can be found on Extensions >> NDepend >> Code Rules Explorer:
It will be opened a list of all the Rules already set, by category and individually as the image below:
It shows if our project already contains points to review (warnings) by category(e.g Security, Dead Code, etc) and if you click at an individual rule, it is possible to change the configuration or create a new query. Everything here is based on LINQ Queries that you are probably already familiar with.
For this article, I’ll change the rule related to the recommendable maximum number of lines for methods. To do that, just click in an individual rule in the Rule Explorer and it’ll show the LINQ query associated to the rule, as follows:
In my case, I want to put the maximum of lines to 50 (It is not so strict). So, I changed in the LINQ Query the criteria to show the warning related to the rule:
The NDepend tool generates an object (JustMyCode) with useful properties related to our base code information.
You can set patterns for namespace, types, names, properties of the classes, Assemblies and much more. It is really that easy to set up.
The query below is given by the tool as an example in how we can set a rule to avoid to call directly the Db Layer in the View / FrontEnd Layer:
We can check if certain assembly as Entity Framework is being used in a specific layer that we don’t want that someone uses it. Within big teams, it is really important to have this kind of automatic custom verification.
Conclusion
I found the tool really impressive and easy to use, install and setup. Considering the huge amount of useful features this tool has, I think that deserves a series of posts about it, explaining details on how we can get better code quality results easily with this tool help. It is only the second article for a while.
So, I’m really enjoying “playing” with this tool. I hope that will be helpful for you.
Thank you for reading this article till the end.
Top comments (0)