Testing is vital. I have previously written how writing tests is important in your code and that you should never put off writing them. Having a solid body of unit and integration tests takes away the fear of refactoring code, as behavior preservation is ensured. Production tests also exist, which can be run against live information to make sure that data integrity is maintained. UI testing is also available; frameworks such as Selenium allow you to test the UI portions of your application with ease.

When writing code it is important to keep good coding principles in mind. Testing helps enforce and maintain good principles in your code; however, it is also important to review the big picture. This allows you to identify questionable areas of code (methods that have grown large, classes that have too many responsibilities, and so on). When up against a deadline sometimes there is not time to write the most optimal code. Some less-than-perfect code has to be hacked in just to complete the task. Ideally, you would want to get back to those points later and clean them up. It would be nice to have some sort of program to analyze your code base and identify those points in your code. Well, I recently got a hold of a product that will do just that.

We here at NimblePros have released a great new .NET code analyzer: Nitriq. You merely load in assemblies or executables from your project and it immediately gives you feedback, which can identify code smells. 

The Treemap window shows a graphical representation of the largest chunks of code of the selected category. At a glance, you can: find out where the most complex components of your code live; find the code that contains the largest methods; locate the classes that contain the most lines of code, and so on. Then you can go in and refactor the code as necessary. The real meat and potatoes of Nitriq, however, lie in the queries that can be executed against the loaded assemblies. Creating your own rules is incredibly simple in addition to having many out-of-the-box queries at your disposal. Nitriq utilizes LINQ in order to create its rules. In no time at all you can implement your own rules via simple LINQ queries. Take a look at the following query:

var results = 

from type in Types

let ConstructorCount = type.Methods.Where(m => m.IsConstructor).Count()

where type.IsAbstract && ConstructorCount > 0 && type.IsInCoreAssembly

select new { type.TypeId, type.Name, ConstructorCount } ;

WarnGreaterThan(results, 0);

Here it is in action:

As you can see, a class is flagged when it is abstract and contains a non-default constructor. In the Grid and CodeTree windows you can discern which classes were found along with other relevant information (in this case, the number of defined constructors). The Treeview window also highlights the portions of your code base that were flagged. This query is one of the many that come with Nitriq. Along with the other queries, it can be easily modified to suit individual needs.

What these metrics and queries give you is another body of tests to run against your code. As with unit and integration tests, these can be used to preserve good coding principles and lead to less bugs found in production code. As you can see, there are many rules that come prepackaged with Nitriq. These rules promote agile software practices. In future posts, I will detail why violations of these rules are indeed code smells and how removing instances of broken rules from code will lead to a better overall code base.