“Make your .NET Code Beautiful with NDepend”
Couple of months ago the developer of NDepend sent me an email offering a license in exchange for an honest review. In this post I will try to give you a brief introduction and a few tricks to make it work with Unity3D. (tks Patrick!)
As a developer one of the most important things you must keep in mind is Code Quality and Maintainable Code. NDepend is a fantastic tool that will help you in this matter. Quoting it’s website, “NDepend offers a wide range of features to let the user analyze a code base. It is often described as a Swiss Army Knife for .NET developers.”
Let’s see what we get using NDepend with Unity3D. First of all, NDepend can’t recognize Unity assemblies out of the box. No big deal though. After installing NDepend, you will find a new menu on your VS. Go to NDepend > Windows > Start Page.
Just ignore the red arrow and click Analyze .NET assemblies in directory. Next window you will select the following assemblies. You can use the filter tool too.
After selecting the 4 .NET assemblies, you are good to go. First thing you can do is check the “Code Quality” set of rules. I’m using a real world code for this post (my current project), so this is how it looks like:
Ok, 96 complex methods. According to NDepend, “This rule matches methods where *CyclomaticComplexity* > 30 or *ILCyclomaticComplexity* > 60 or *ILNestingDepth* > 6. Such method is typically hard to understand and maintain.“. Keep in mind that this tool won’t fix anything, it’s an analysis tool. It’s up to you refactor your code.
Double clicking “Methods too complex – critical” above leads to another very usefull window (above). I grouped all 96 methods by namespaces. If you are a Unity developer you may recognize most of the namespaces listed. They are third party assets/plugins, “TM” is my project namespace and that’s where I should look. Afterall, I have only 12 critical methods. not bad at all.
“NDepend lets query the code base over LINQ queries thanks to CQLinq.”
NDepend is great because you can create your own rules. This is how you create a rule to filter your own code (if you wrap your code in namespace(s)). Thanks to CQLinq, this is very easy! In your Queries and Rules Explorer Window (NDepend > Window > Rule Explorer) you will find all active rules for your projects. Find the rule Defining JustMyCode, right click and create a Child Query.
Now you will see a little window somewhere where you can type something. In my case this is what it looks like:
// <Name>Filtering 3rd party namespaces</Name>
from t in Application.Namespaces where
t.Name != "TM" && !t.Name.Contains("SevenSails") && !t.Name.Contains("MicroUI")
This is what I got from a quick searching: Most of the default rules (but not all) uses the domain JustMyCode to query your code. The code above defines a prefix “notmycode” that runs before any JustMyCode query. So here I’m saying that every namespace that is different from “TM“, “SevenSails” and “MicroUI” won’t be included on JustMyCode queries. Just enable that checkbox and you are good to go.
Here is the difference after filtering namespaces.
If you are using NDepend and Unity3D, there are few things you need to be aware. For example the “Dead Code” rules. More specifically the “Potentially dead Methods“.
Many methods here will be a false positive. Start/Update/OnEnable/OnDisable/OnSceneGUI and many others are not dead methods and you probably want to filter it from this rule. To change this, open the window Queries and Rules Explorer, and edit the Potentially dead Methods query:
Inside canMethodBeConsideredAsDeadProc, add the following lines:
Save it and you should see the difference. In my case, only 11 methods were found as potentially dead.
It’s a great tool to help you at the late stages of your project. Checking the built-in rules will give you a better code for sure, but when you think about all the power of the Linq queries, you realize you have a world of possibilities at your hand. You can download a 14-day Trial at their website and try it yourself.