if (myName.Equals("..."))

Resharper will generate simply

if (myName != null ) { if ...

Nope, it is not that stupid. It first analyses the usage of the variable and might even create a new code level (using { }) so that not only the one line is being properly checked, but also the following lines that depend on that variable.

The null-check is only a very easy example. ReSharper offers extensive anaylsis features that always take your code into account and I have not had a single case that my code did not compile or the code was not yielding the same result as before the transformation. Variable types are also handled perfectly by ReSharper so that you can invoke “type-safe code completion” (my personal term). If you call a method and it expects a certain type, code completion will not only list the types, but will also complete the line for you, if there is only one variable of the matching type in the current namespace available. It is just a huge time safer when writing code!

However, my favourite feature so far is that the software really knows usage patterns. E.g. if you write

List<Customer> customerList = getCustomerList();

And you then write

foreach

and press <Tab> it guesses (!)

foreach ( Customer customer in customerList )

It would not be so amazing if you could not “toggle” the different variable names to be used. E.g. ReSharper offers you many possible variable names if you use camel case or another known way to name your variables. One thing is sure though: if you use ReSharper you definitely have to write a huge amount less code.

There is a trial edition available on www.jetbrains.com . Students get a really fair bargain and there are special licenses for educational institutions available.

You can use NDepend in association with many products. There is an IDE integration for Visual Studio and Lutz Röder’s Refelctor available, for example, but you can also start a seperate GUI that allows you to select the source you want to analyse. An analysis consists of two things: For one, a huge easily navigable report in html format will be generated. Furthermore, and this came as a surprise to me, as an earlier version of NDepend did not offer this tool, the GUI has been extended so that you can query and browse the results. This is actually what makes this tool so useful. We all have heard the principle of creating “loose couplings” between separate source code groups. E.g. you should encapsulate persistence, user interface and business logic seperately. Can a tool like NDepend help me to verify that I succeeded in doing so? You might have guessed that this is a rethorical question…so…yes.

Thus, I do not want to list all the fancy features that NDepend offers you (you can simply look them up here: http://www.ndepend.com/Features.aspx), instead I want to offer an example why NDepend is something I do not want to miss anymore while developing applications.

So, let’s get started with the example.

People, who attend my sessions about ECO, will always hear: ECO will take care that you get a great basis for encapsulating your code properly. Fine. But does it really? Did I do something while writing my application that defies this princriple?

To verify this statement, I started the NDepend Graphical User Interface (aka VisualNDepend.exe) and selected the assemblies my application consisted of. Be aware, if you analyse an application that is built upon a framework, you should include the framework assemblies as well. After selecting my assemblies, I generated a report (it’s a click of a button) and directed my attention to the dependency matrix. Sounds geeky and complicated,  but it is not. Every row and column are labeled with the name of  a namespace. The numbers in the cells designate the number of types, members  etc. (you can actually select that in a combo box) used by the other namespace. So, looking at the screenshot below, we want information about the number of types used in the different namespaces.

Interestingly, we can clearly see that any persistence operation is only being dealt with in the Eco Space as the Eco Space embodies the Persistence Mapper and the Data Connection Components. How can we see that? Look at the namespaces Eco.Persistence and its sub-namespaces. Any type from that namespace is only used by the EcoSpace namespace, but not by the business model, which is in the namespace marked with “.Model”. Same applies to any class from the System.Data namespace, which includes all the database-related classes in .NET. On the other hand, System.Windows.Forms, which contains all the GUI classes, is not being used by the EcoSpace or the business model. Thus, my encapsulation is perfect in this example and NDepend made it really easy to verify.

As the matrix is a tree you can  drill down in any of the namespaces and get detailed information. You can also double click on any of the numbers in order to get a graphical representation in a state-machine-like fashion that allows you to quickly get a clear view on the structurre of your code.

This is just one brief example how NDepend can really make your life easier. If I encounter another useful result that also proves my points about what I say about ECO in my sessions (*ironical grin*), I will post it here asap.