Code quality should be a high priority for a coder. NDepend is a tool that helps coders to sniff out the smells in their code. After a friendly chat with the NDepend's author, Patrick Smacchia, I got started using the tool on my projects.
Installation on Linux
The functionality of NDepend on Linux or Mac is not as expansive as on Windows. Installing NDepend on Linux is described here. It boils down to downloading the binaries and running a command to register the license. After registering the license, you can generate a report for a solution. Applying NDepend to a solution is fairly simple. The CLI creates a .ndproj file that we can use to generate a report. Report generation is the same functionality that you would use in a build server and is in an HTML format. I simply host this on a local web server.
NDepend gives you a score on the amount of technical debt in your solution. I'm quite happy that I've received an "A" rating. However, my code isn't perfect. 3.52% debt as you can see. There are many things that the report picks up that Visual Studio or Rider doesn't. Here are some of the things that I experienced.
- Smurf detection: 'Avoid prefixing the type name with parent namespace name'. It does happen quite a bit in my code base.
- Avoid methods with too many parameters: This is often a sign that the method does too much and the code should be split up.
- Avoid types being too big: This rule matches types with more than 200 lines of code.
- Avoid having different types with the same name.
- Attribute class name should be suffixed with 'Attribute'
- Avoid non-readonly static fields.
NDepend lets you see the debt per namespace. A nice way to determine debt in a certain area of your code. You can also set the parts of your code that don't need to be analyzed.
A few improvements on the Linux side
NDepend does offer the functionality for Linux and Mac users, but the richest experience is offered to Windows users.
- Tooling for VS code or Rider: Visual Studio has a plugin, but no other IDEs has this.
- A nicer CLI experience: Calling dotnet with a fixed path isn't the perfect CLI experience. Perhaps offering NDepend as a dotnet tool that can be updated with ease. Maybe something like this: "dotnet ndepend $path $project"?
Just scratching the surface
I've just been using the tool for a few weeks and will be exploring NDepend more in the future. I recommend reading about the rules to truly understand the scope of this project.