A key factor to being a successful developer is writing good, solid, maintainable, error free code. It seems like a pretty obvious – albeit innocuous – statement, so why state the obvious? When you check code into the main branch of the source code for your organisation, you immediately expose your abilities and disabilities as a developer to the people you work with and for. If you check in a bad bit of code that contains bugs, it usually isn’t you that first notices the bug, but a colleague and you can look inept, especially if it is a silly mistake (and you have made a few of them – your boss may start thinking you are inapt to continue in your role in the company).

Writing good code is very difficult, especially when the code base is changing rapidly so you as a developer need tools that can make your life easier. The more experienced you become as a developer, the more you look to ways of making your life easier. Jetbrains have a visual studio add-in called ReSharper that is a little like FxCop, which the smarter developers amongst us use. If you are wondering why some developers seem to produce very clean code consistently that omits silly bugs (even on a Friday afternoon), you will more than likely find that they are using ReSharper.

I don’t doubt that a lot of people may dislike the fact that this takes over your IDE (this really is for the better though), in fact, If I recollect correctly I tried ReSharper a few times, then removed it (after a few word of mouth trials) every time because my IDE was less responsive, and because I was impetuous. It was only when I released a test application to a customer a few months ago (that kept crashing unexpectedly), when desperation set in, and drove me (frantically) looking for errors in my code. The main culprit  (in this specific instance) was a handful of null references in the codebase that had gone unnoticed, that ReSharper readily identified and I corrected, consequently achieving rapid application stability, over the course of a few days long code review. I’m not saying that all my problems were fixed, but most of the niggling issues were, with little to no effort.

It is not just null checks that ReSharper identifies, but a pretty comprehensive set of common coding mistakes that even the best programmers frequently make. The ‘Big Win’ is in that you get to correct problems there and then, as the code is written, before it becomes an issue. Visual Studio 2008 introduced background compilation that surreptitiously increases developer productivity by showing them errors as the code is typed, rather than waiting to press F5. ReSharper is orders of magnitude more helpful, if you use it correctly, you end up with a very clean codebase, with no unnecessary code, that has had common errors identified, giving you the developer confidence in your code.

To show a few basic examples

Here I can remove the redundant delegate constructor call that the IDE generates. I can also remove the this keyword. The this keyword is rather abused in C# (Me in Visual Basic) and a lot of code samples (even from Microsoft) show developers misguided bliss with the word. One only ever needs to use the word when you have two variables named the same in a class (typically in a constructor) like this

In most other cases it is redundant to use the word.

In the sample above there are several issues. I have dead namespaces at the top, a poorly named control, two poorly named variables, that can also be made readonly. This is just an iota of the static runtime assistance that you get as a developer, and you can adopt the mantra of “writing a little code that does a lot”, rather than “writing a lot of code that does a lot”, with significantly less bugs.

I strongly encourage you to download this tool, acquaint yourself with it, and start working a little smarter (even on Friday afternoon).

Before a parachutist, mountain climber or formula one driver undertake their tasks, a number of checks need to be undertaken. These checks will assist in deciding whether the parachutist for instance will even jump out of the plane. If a typhoon is on the way, all are likely to wait until it has passed, the type of climbing gear the mountain climber will choose, must depend on the type of mountain they are to climb. What all these checks result in, is less surprises, in computer programming this is analogous to bugs.

I know that architecture is ubiquitously used to describe engineering software, but the comparison is indeed an irresistible one. Take the Ironbridge in Shropshire for example, every element of this engineering feat must have been stress tested. The materials must have been tested to see how they react to temperature changes, weight and so forth. You can even find out how many rivets they used, and the length of the steel used in the bridge, all wonderful and useful information. Shropshire bridge (as I’m sure your well aware) is not the only bridge in the world, as there are a great many others that come in different shapes and sizes and age. The design process for a lot of these constructions requires a similar set of circumstances and considerations. A formula one motor car for example, still has four wheels as does a mini cooper. Writing software is no different, and most if not all software projects entail a similar set of circumstances and considerations, whether massive, big or small, you still want to deliver a fast, efficient, reliable and effective application.

I have recently started using NDepend, to quote from their website;

NDepend is a tool that simplifies managing a complex .NET code base. Architects and developers can analyze code structure, specify design rules, plan massive refactoring, do effective code reviews and master evolution by comparing different versions of the code

If you prefer the ribbon, you can change the user interface to suit

The way I look at my code has been changed forever. What you get is an abundance of relevant and pertinent information about your code, that you never thought possible. NDepend is about assisting you the developer (whether a single man outfit or team) to ensure that you are producing the highest quality code possible. There is so much information at your fingertips, it is overwhelming.

The Model View Controller, Model View Presenter and Model View View Model design patterns for example, are all about separating the concerns of your code, and increasing the testability of your code base. NDepend is another necessary tool, in that when you perform code reviews, it becomes an indispensable tool. Architects for a project can set rules for the code base, and easily check to see that they have been adhered to from a quality point-of-view, and developers themselves can ensure that they remove any sloppy code they’ve written, and spot anomalies and problem areas before they check in their code.

Here I have just loaded an assembly for an application that I wrote a while ago. I have a pane (one of many) that furnishes me with information about the number of lines of code I have for instance, comments, methods, fields and types.

In another pane, you have information pertaining to code quality, methods that are too big, methods that are too complex, methods to refactor, methods with too many variables, methods with too many parameters, the list goes on and on. Each point an important code quality concern.

In the same pane under design, you have suggestions that stateless types in the code could be changed to static types, or that a class without a descendant should be sealed, and again a myriad of other code quality issues that need to be addressed.

Why should it be sealed? The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.  You have 5 classes here that can be changed to Structs, improving performance as they are now value types and not reference types from a .NET runtime standpoint.

You have Visual studio integration, Reflector integration and a wealth of other features.

An issue any Software architect or Developer always runs into is performance and trying to ensure that their code is as optimised as possible, ensuring that their end users have the best possible experience when they use an application. I have always used this article every once in a while to ensure that my applications are structured correctly, and refer to it every now and again (most of the article is relevant to Silverlight and WPF as well). Clearly by using NDepend you will end up with better performing applications, and also more maintainable codebases, because all the ‘gremlins’ are ‘found out’ soon and the more you review your code with it, the better quality your code will be as a result.

NDepend is an essential new development tool, that I will blog about more, once I understand it better.