As developers, we are constantly surrounded by rules. Rules for code-style, rules for better performance, rules for good design, but who is setting those rules?
For a lot of devs working in medium to large corporations, it’s a senior dev who has the final sign-off on code conventions, which is fine. Consistency is usually more important than checking every box in ‘Uncle Bob’s set of rules for clean code’ (which I have the utmost respect for as the bible of coding practices that it is.) But could we not make it easier for ourselves? We are in the business of automation are we not? What if we could have our code checked using a prime set of rules, as we code?
This is no new thing, with JetBrain’s ReSharper being one of the more well-known players in the code-analysis space. But let’s go back to our question around who sets the rules for code style. Yes, I already said that most medium to large corporations have more senior devs that have the final say on such rules but what if you’re in a small team? Or more precisely, what if you’re in a team of one?
This is where I’d like to introduce the tool that I think works well for solo developers or small teams or even students who are looking to improve their practice – NDepend.
Now, don’t get me wrong, this tool is more than adequate for the largest of dev teams, or even departments containing many different yet co-dependent teams, but that’s not how I used this tool. I’m here to talk about how useful the tool has been for me as a dev working outside of the usual team environment. On side-projects and exercises in improving my overall coding chops.
So let’s dig into the product a little deeper.
What is NDepend?
NDepend’s applications are pretty vast but in short, it’s a Visual Studio extension that not only improves your overall style when it comes to writing code in .NET, but also improves the health of your application, and allows you to anticipate things you are adding now, that may affect you later.
NDepend describes itself as The “Swiss Army Knife” for .NET Developers, Architects and Teams, and I couldn’t agree more. In my short time with the product, I’ve seen ways my project could benefit at the code level but my ‘Software Architect mode’ kicked straight in with the potential ways to show the payoff or consequences of particular architectural decisions. The dashboard you see above gives a bird’s eye view of the current health of my codebase as well as useful pieces of information about what I’ve built.
Stats Stats Stats
As you can see above, I can evaluate the way I am coding as I do it. The dashboard was great for providing interesting pieces of data, like the number of code lines I had written and the estimated effort I had spent writing them. This is particularly good in a team situation, as you could use the tool to evaluate team member’s performance and spot if certain sprints were taking longer than others. It’s still very useful as a solo metric for my own understanding of my current pace, but I think this, in particular, is more suited to a team.
I loved the fact that the various types living in my project were summarised in one place for me to see. Clearly my project has a lot of third party elements in it. 356 at the last count. This might make me evaluate the use of third-party libraries. Am I using too many? NDepend will help me decide. There is a downside to this though, in that the third party element listed when I click them, include elements from the System namespace. More often than not, in a .NET project (although I admit not always) ‘System’ is going to be in use. ‘Third-Party Elements’ suggested to me that it would only list elements from outside the .NET Framework, listing non-.NET libraries exclusively. I don’t know if there is a way to change it but all in all, it’s a very minor complaint.
Keep it Simple, Pay your Debt and Get Covered!
This area of the dashboard is one of the most useful in my opinion. First off, NDepend is peering into the future to see how much technical debt you have accrued so far. Being one of the most detrimental contributors to project woes, I think the fact that NDepend is addressing debt in real-time is a real selling point of the product. Not only does it give you a grade, (I got an A at the moment, just saying), it predicts the amount of time it will take to pay the debt off. What’s more, clicking the debt percentage takes you to a list of issues to be fixed to pay off the debt.
I think solo developers in particular often overlook technical debt and often are unaware of how much they have accrued until the amount is large. This has helped me to keep on top of it for sure.
Also shown above is the coverage section. I didn’t get around to playing with this too much as the tool expects you to import test coverage data. I was kind of hoping that NDepend would have the ability to process coverage natively, or if it does, it’s not clear to me where this is possible. Maybe a feature request is in order? Granted unit testing is not necessarily what we are concerned with here, as we are largely looking at the structure of our code rather than how we are testing it.
Finally, for this section, we can see the level of complexity exhibited by methods in our codebase. This is an excellent metric for spotting where your lack of abstraction is letting your project down.
Rules, Gates and Issues
Quality gates in NDepend are entities that produce a status based on whether a pre-defined rule was met. I can see that this would be very useful for prepping code for QA or release, as you can draw the line as to when you halt a release based on the amount of failed quality gates. Also, NDepend has an API, so this could easily become part of your CI/CD pipeline.
Out of the box, the quality gates conform to the rules that come baked into NDepend. It’s important to note that custom quality gates can be created so that you can enforce your own rules for the pass, fail or warning statuses outputted by these gates. I don’t think the interface makes enough of a fuss about the fact that you can create your own quality gates, with the documentation being the first place I saw it. This feature is so important despite the extension being relatively modest about its presence.
The use case for rules and issues are pretty much the same as the gates above but I think they would be more useful during development as a real-time indicator as to how ready you are to ship.
Breaches of rules are easy to find within your code thanks to the Rules and Debt screen. Here I can find any rules I have broken with a handy explanation of how that rule warning is triggered. I can choose to ignore it if I wish, or double-click the issue and see the offending piece of code. Fix the issue, run NDepend again, and you will likely have squashed the warning. Pretty simple and a nice way of improving your code as you go.
I find it fascinating to see specifically which category of rules I am following or breaking. NDepend is pretty explicit in stating why you went wrong. As shown above, 9 of the issues flagged for me by NDepend were deemed to be code smells. If I’m soloing, I wouldn’t have a peer review to help me pick this up, so I appreciate having an automated process fill that gap.
A Lot of Love for Architects
NDepend has architects in mind. With the click of the button, I was able to generate a pretty concise dependency graph for the project NDepend was attached to. Namespaces, classes, types, scopes, they’re all mapped out cleanly and logically for me to evaluate. I like this feature. As it is mapping out existing code, it may not always be a goto for architects, who may have dropped the mic and walked out by the time the code is being written, but on the flip side, it may also help devs to connect to their inner-architect. I could see this being improved specifically for architects if NDepend added a comparison feature – something with which the current dependency graph could be compared with the initial design, that way we could see how on close we are following a design during the development process. I’d happily draw out my initial designs in NDepend if I knew I could compare them against real-time maps later on.
Not a Resharper Clone
NDepend differs pretty significantly to JetBrain’s Resharper mainly in the way it analyses your code. While Resharper analyses in real-time, telling you when you are breaking rules of practice as you break them, NDepend computes this when you ask it to. This is essentially the decider for me between the two products. I’ve used Resharper in the past and I honestly think it’s an incredible tool. However, the performance hit I get from it running in the background constantly was too much for me. I also like to be able to stop at a certain point and start reflections on what I’m writing, refactoring if needed. NDepend suits this way of working for me. It gives me feedback when I tell it to, and that’s enough. In terms of price, NDepend is a couple of hundred dollars a year more expensive than Resharper’s annual subscription, but I think you get more bang for your buck. I honestly feel that it’s a decent investment for solo devs looking to enforce the same standards followed within the industry by teams.
I’ve barely scratched the surface of what this tool can do, which is why I suggest you check out the website for more info. It’s not the prettiest I’ll grant you that, but I don’t think it needs to be. What it lacks in flash it makes up for practicality and time-saving. I honestly think this tool will make me a better developer. I work in teams daily but I also spend a lot of time writing code alone, and it’s in doing this that we can often let our standards slip. With NDepend on the beat, I’m being held accountable for my code even when I’m working alone which is a small price to pay for being a more humble and hopefully thoughtful programmer.
