Improving code quality – 2 ways to go

I’ve been thinking about this for at least a week or two. In fact, it’s been since I started (and finished) reading the book “Clean Code” by Robert C. Martin. There is probably only two way to go.

Fix the bad code

This method is called refactoring and “cleaning” the code. This of course, you can’t truly know what code is bad without having a Static Analyser tool or programmers working on the code. The tool will allow you to spot piece of code that could bring bugs and/or be hard to work with. The problem, refactoring code or cleaning up code is really expensive on a business perspective. The trick is to fix it as you interact with the code. It is probably impossible to request time from your company to fix code that could cause bugs. If you ask your company to fix the code, you will probably receive this answer: “Why did you write it badly in the first place?”. Which brings us to the other way to improve the code quality.

Don’t write it

If you don’t write the bad code in the first place, you won’t have to fix it! That sounds simple to an experienced programmer that improved his craft with years but rookies will definitely leave bad code behind. Eventually, you will have to encounter this bad code. So how do you avoid the big refactoring of mistakes (not just rookies)? I believe that training might be a way to go. When I only had 1 year of experience in software development, I was writing WAY too many bad code. I still do. Not that I don’t see it go through. Sometimes, things must be rushed, I don’t understand fully the problem and some small abstraction mistakes gets in. I write way less bad code then when I started. However, this bad code is not just magically disappearing. It’s stays there.

What about training?

I think that training and/or mentoring might be the way to go. Mentoring might be hard to sell but training is definitely not that hard to sell. Most employees got an amount of money related to their name within a company that represent training expenses that can be spent on them. What I particularly recommend is some courses in Object-Oriented design or Advanced Object-Oriented Design. Hell, you might even consider an xDD course (and by xDD… I mean TDD, BDD, DDD, RDD, etc.). Any of those courses will improve your skill and bring you closer to identifying clean code from bad code. Other training that will form you specific framework (like ASP.NET MVC or Entity Framework) will only show you how to get things done with those framework. The latter can be learned on your own or through a good  book.

So? What do you all thinks? Do you rather have a framework course or a “Clean Code” course?

So I just finished reading Clean Code by Uncle Bob

This must have been the most enlightening book I’ve ever read. It’s filled with “evident” knowledge. Of course, some of them you have never thought about… but some that you just can’t avoid nodding in approval.

As everyone know, I’m a .NET Developer and Uncle Bob is a Java developer (not exactly but the book have code in Java). There is some recommendation in the books that are targeted at Java developer and that don’t apply to .NET.

So? If I had to tell what the book is about, what should I say?

I would say:

• Humans are good at mixing abstraction level
• Keep the variable/class/function clear and concise
• Commenting must be done with care otherwise it just clutter the code
• Refactor, refactor, refactor. A code base is never perfect but if you follow the Boy scout rule, the code base will always be better in the end
• Code should always have test and high coverage

Am I hitting the bulls eye here? What do you think?

Redefining ALT.NET or rather, rediscovering it’s meaning

I’ve heard about ALT.NET about a year ago. At first, I thought that it was about using alternatives to Microsoft or to avoid Microsoft software. ALT.NET was supposed to be about going “alternative” and being against “The Man” and being for “The People”. Well, I must agree that I wasn’t totally right with that. I mean, Microsoft make some mess but it also does a lot of great tools and particularly a great IDE with lots of extensibility point.

Then, I did what I should have done in the beginning. I looked up the definition. On the ALT.NET website, we have this:

We are a self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.

Hum… that’s a totally different story now. The emphasis is mine and helps get the key points. First, I would have never gotten into a field that I hate and I love to learn. That makes the desire to improve ourselves done. I always challenge assumptions and try to find the better tool for the job. I know that Microsoft makes some great tools but sometimes they just don’t cut it. They will someday… but they not always will. Most of the time, you can’t wait for Microsoft to build a tool that will help you finish a software… so you get what works for you at the moment.

Finally and not last, “help each other pursue excellence”. That is the hardest one. Of course, I participate in the .NET Montreal Usergroup, but… I felt that more could be done. I then started to speak with Greg Young and other passionate programmers in Montreal. Something that Greg kept repeating during our “Beer Meeting” was always: “But what concretely can we do to improve the level of the people in Montreal?”. This stayed in my mind for weeks.

Since I wanted to help improve my fellow programmers and I thought that we learn best while coding… I started searching for a way to improve everyone while coding. It happens that it already exist and it’s named a Coding Dojo.

Last Thursday, I organized the very first Coding Dojo for the ALT.NET Montreal group. We were few but learned a lot. We also had a lot of practice in learning TDD. It was hard since I never did a Coding Dojo before. I learned a lot, and our fellow programmers learned a lot. I’ll try to get one Dojo per month and to get more and more people to join the group. As Kevin Coster was told… “if you build it, they will come”.

So my last word goes to Scott Bellware. All hope is not gone Scott. People around the world is still organizing to teach other people best practices and to try to raise the bar of everyone. Our group is small… but if it had to start somehow it had to be small. I hope all hope is not gone on your side Scott. Passionate programmers love to learn and we are trying to offer them a way to learn and improve themselves and at the same time… propagate their knowledge to the workers that didn’t cared enough to come.

TDD: How I applied TDD to a simple problem

A month or two ago I had to built a component that had to analyse a string a return some information out of it. The best result for this was a Regular Expression and I was sure. So I started writing what kind of input would be valid and which one should not be allowed.

When I started writing this code, I already read many blog posts about it and wanted to give it a try. Since I wanted a simple scenario which would easily be applied, when I had to parse this string I knew I had a simple problem to which I could apply it.

If anyone has ever worked with regular expressions, it is widely known that it’s easy to make something match. However, it’s really hard to make it match what you want and not what you don’t want. For proof of that, try seeing how many regular expression there is to parse a phone number. The non-matches is as important as the matches.

So I started a test project and added my first test. The test was to test the perfect scenario. Of course the test didn’t even compiled. I then proceeded to create the missing classes and made the test compile. Of course, all the class had the following inside them:

throw new NotImplementedException();

This ensured that the test “went red”. I then proceeded to implement the minimum necessary to make it pass and make it “go green”. And I kept on rolling until it worked in all my specified cases. Sometimes, previous tests went and failed. Sometimes, everything stayed green but I kept on going.

For experienced TDD-er it’s common and normal. But for me, it was weird. I made sure to follow EXACTLY what it said. When it said “minimum necessary to make it pass”, I made sure that I returned a constant if I could or proceeded to create/modify the regular expression as needed. And as I kept increasing my amount of test, the constant all went away, the regular expression got more precise and every time that I broke a test I came back to fix it. It’s a weird feeling but when I gave my class for usage, it was working as perfectly as it could.

So why the ruckus? Because since I wrote this piece of code, I haven’t seen one bug report. The code is perfect for what it is doing. When a bug will come my way, I’ll try the TDD-er way of doing thing. Add a test that reproduce the bug and fix my code to make sure it works on all test.

Result of everything? One bug ridden class, 20 something tests and one developer who learned the essence of TDD.

I would love to get my teeth on more complex code now.

Part 2 - Basic of mocking with Moq

See also:  Part 1 - Part 3

As every mocking framework, except TypeMock which can perform differently, every mocked class can't be sealed and methods that need to be mocked need to be public. If  the class is not inheriting from an interface, the method that are being mocked need to be virtual.

Once this is cleared... let's show a simple example of a Product having it's price calculated with a Tax Calculator.

Here's what we are starting with:

public class Product
{
 public int ID { get; set; }
 public String Name { get; set; }
 public decimal RawPrice { get; set; }
 public decimal GetPriceWithTax(ITaxCalculator calculator)
 {
     return calculator.GetTax(RawPrice) + RawPrice;
 }
}

public interface ITaxCalculator
{
 decimal GetTax(decimal rawPrice);
}

The method we want to test here is Product.GetPriceWithTax(ITaxCalculator). At the same time, we don't want to instantiate a real tax calculator which gets it's data from a configuration or a database. Unit tests should never depend upon your application's configuration or a database. By "application's configuration", I mean "App.config" or "web.config" which are often changed during the life of an application and might inadvertently fail your tests.

So, we are going to simply mock our tax calculator like this:

//Initialize our product
Product myProduct = new Product {ID = 1, Name = "Simple Product", RawPrice = 25.0M};
      
//Create a mock with Moq
Mock<ITaxCalculator> fakeTaxCalculator = new Mock<ITaxCalculator>();

// make sure to return 5$ of tax for a 25$ product
fakeTaxCalculator.Expect(tax => tax.GetTax(25.0M)).Returns(5.0M);

Now It all depends on what you want to  test. Depending if you are a "State" (Classic) or "Behaviour verification" (Mockist), you will want to test different things. If you don't know the difference, don't bother now but you might want to look at this article by Martin Fowler.

So if we want to make sure that "GetTax" from our interface was called:

// Retrived the calculated tax
decimal calculatedTax = myProduct.GetPriceWithTax(fakeTaxCalculator.Object);

// Verify that the "GetTax" method was called from  the interface
fakeTaxCalculator.Verify(tax => tax.GetTax(25.0M));

If you want to make sure that the calculated price equal your product price with your tax added (which confirm that the taxes were calculated):

// Retrived the calculated tax
decimal calculatedTax = myProduct.GetPriceWithTax(fakeTaxCalculator.Object);

// Make sure that the taxes were calculated
Assert.AreEqual(calculatedTax, 30.0M);

What's the difference? The first example verify the behaviour by making sure that "GetTax" was called. It doesn't care about the value returned. It could return 100$ and it would care. All that mattered in this example was that GetTax was called. Once this is done, we can assume that the expected behaviour was confirmed.

The second example is a state verification. We throw 25$ inside the tax calculator and we expect the tax calculator to return 5$ for a total price of 30$. It wouldn't call GetTax and it wouldn't care. As long as the proper value is returned, it's valid.

Some people will argue that behaviour is better than state (or vice versa). Personally, I'm a fan of both. A good example is that I might want to verify that an invalid invoice will not be persisted to the database and a behaviour verification approach is perfect for this case. But if I'm verifying (like in this case) that the tax were properly calculated, state behaviour is more often than not quicker and more easier to understand.

Nothing prevent your from doing both and making sure that everything works. I'm still not a full fledged TDD developer but I'm trying as much as possible to make tests for my classes as often as possible.

If you found this article helpful, please leave a comment! They will be mostly helpful for my presentation on February 25th 2009 at www.dotnetmontreal.com.

Part 1 - Introduction to Moq

See also:  Part 2 - Part 3

This is the first post of a serie on mocking with Moq. I'll be giving a conference a .NET Montreal Community on February 25th and I though there it would be good reference to anyone attending the @Lunch event.

What is Moq?

Moq is a mocking framework like RhynoMock and TypeMock jointly developed by Clarius, Manas and InSTEDD. It heavily use Lambda to create expectations and returning results. It's been highly criticized as not making any distinctions between Mocks and Stubs.

What is import to remember, is that unless you are philosophically attached to your testing style... most developer don't make any different between them and rather do behaviour testing.

Moq easily allows you to change it's behaviour from "Strict" to "Loose" (Loose being the default). Strict behaviour won't allow any calls on the mocked object unless it's been previously marked as expected. Loose will allow all calls and return a default value for it.

There is a lot off more advanced behaviours that can be configured and used.

Why another mocking framework?

Daniel Cazzulino (A.k.a Kzu) blogged a lot about Moq and even compared why he helped in creating Moq. Moq was created to ease the learning curve of learning a mocking framework while blurring the distinctions between mocks and stubs.

Moq allow you to quickly get into mocking (a good thing) while allowing more complex scenarios by more purist mockists. It's the perfect mocking framework if you have never touched a mocking framework and is your first experience.

Where do I download it?

You can download Moq directly here. At the moment of writing this post, Moq was at version 2.6.1014 and Moq 3.0 was available as a beta.

How to install it?

Once Moq is downloaded and extracted from it's zip file, you can easily add the single DLL (Moq.dll) inside your project install it inside the GAC if you are going to use it on many projects.

Stay up to date

After this brief introduction, I'll show more advanced feature of Moq with code sample on how to use them and why to use them.