Leandro Boffi. Cloud, Identity, Mobility and Software Architecture.

I’ve this problem a thousand times: How to explain to your manager or to any not developer person that you are expending working time on improve your code quality? The only clue that this not developer person may has about you are saying the true it’s if your code quality improvement also was a performance improvement, and they can feel it when running the application, but it not always happen.

One lesson I’ve learned from TDD is the fact that any objective you take must be testable, verifiable or measurable. With code quality is the same, we are engineers (or we’ll be some day) so we need metrics, but first we need to define a quality bar.

Through my admired college Johnny Halife I’ve meet Eric Brechner. Johnny is the Engineering Excellence Director at Southworks and Eric has the same position at Microsoft. The book I. M. Wright’s Hard Code from Eric Brechner about software quality is a must read for any software engineer.

I was reading this post from Eric’s blog when I’ve the idea of writing this one. Eric says something I’ve heard from he before, let me quote his post:

The two keys to successful big projects (100K+ LOC) are thinking ahead and defining done. Thinking ahead is about design and planning. Defining done is about setting a quality bar and sticking to it.

That’s exactly the first thing you must do, define a quality bar and stick to it.

Before you continue reading, the next section is specific about Microsoft .NET platform. In my next lines I’ll show you three quality code metrics that you can take and an example of this quality bar.

I met this tools working at Southworks, at that time we worked with Microsoft teams and we shipped architectonical and code samples of using Microsoft latest technologies, so as you can imagine our quality bar was high.

1. Source Analysis: Defining an automated code standard.

I’ve seen many times people writing standards of naming conventions for methods, types, variables, etc. The result of that is a 400 pages document with standards that no one developer will read before start coding, that’s not agile at all.

The first tool I want to share with you it’s called Microsoft StyleCop. It’s a free tool developed by Microsoft that has the ability of analyze your code in order to maintain an unified style. Let me show you how it works.

You can download and installed it for free, and a nice “Run StyleCop” option will appear by click right button over a project or solution.

Once you’ve run StyleCop you will see the warnings in the error list panel.

Just fix this warnings and your code will be StyleCop compliant, this means that all your code will be standardized. It can be hard at begin, but with time you will learn the StyleCop rules and you will code StyleCop compliant.

So there you have your first code quality metric, Source Analysis. Now you can say to your manager “hey, my code has quality because is standarized, it has 0 Source Analysis Warnings/Errors”

2. Code Analysis: Ensuring Microsoft .NET best practices

As I say before, many people lost time writing and writing standards for coding. Please don’t reinvent the wheel, Microsoft has his own 480 pages standard and is published on Amazon, It’s called Framework Design Guidelines and it goes by his second edition. The authors of this book work and worked in the .NET framework development. Through this book they share his experiences and define a naming convention, idioms and patterns to work with the .NET framework in the best way.

Great! we don’t need to write the standard, but we still had the problem that buy this book and read 480 pages before start working is not agile at all. To avoid this Microsoft provide us a cousin of StyleCop, It’s called FxCop.

Just like StyleCop, FxCop is a free tool developed by Microsoft that has the ability of analyze your code, and your design in order to make it fit with the  Framework Design Guidelines idioms and patterns, It will report possible improvements in areas like performance, security, design and localization.

FxCop, also know as Code Analysis, will ensure you that you are using the .NET framework in the best way possible. This is how a result of code analysis looks:

If you want to know why FxCop recommends this changes you can go to the book and find the answer, but you don’t have to read all the book before start coding. As bonus you will learn to use better the .NET framework.

FxCop is included in Visual Studio 2008 SP1, but you can download it separately here.

So, that’s your second quality metric, Code Analysis. Now you can say “hey, I’ve been working to increase our code quality, we had 100 CA Errors, and now we have 0 CA Errors, this means our code is more secured, has a better performance, and has a better design”

3. Code Coverage: If is covered is tested

Code coverage is a metric that will ensure the maintainability of your code. It’s basically the percentage of your code that is covered by automated tests.

The code coverage tool is integrated with Visual Studio 2008.

This is how Code Coverage results looks:

A way of maintain a good CC is to work with TDD.

So, that’s all, SA, CA and CC, three metrics to measure your code quality. Now you can define your quality bar as: “0 SA, 0 CA and 85% > CC”, that’s an idea…

Conclusion

By using this tools maintain a good code quality do not requires of writing or reading largest documents or have high technical skills. Code quality is very important because it will be the key of the development and maintainability of your project.

And remember, keep it simple, code quality is something very important in any kind of project. Code quality by itself cannot define the success of your software project, but it can define the failure of it.

One more thing, be carefully, all this is about code quality, no software quality. Software quality is about requirements and if we fit them right or don’t, performance and another kind of things.

Hope you like it!