Follow me on:

Syndicate

Syndicate content

Does TDD lead to inefficient algorithms?

Submitted by Eric Schäfer on Mon, 11/02/2009 - 20:01

Bob Martin showed in a recent blog post "Echoes from the stone age" how TDDing a sorting algorithm would lead to good ol' bubble sort. That stirred up a heated discussion if TDD is really worth it, if it leads to "inefficient" algorithms.

Nobody ever claimed that TDD is supposed to find algorithms that are optimized. TDD at function level defines the behaviour of functions. The behaviour of a sorting algorithm is that an initially unsorted list is sorted after the algorithm has been applied. Well, that's exactly what bubble sort does.

What are you optimizing for anyway? Speed? Memory consumption? Those are behaviour too (temporal and spatial), but they were not specified in Bobs requirements (a.k.a. tests). If you need a sorting algorithm that sorts a certain number of elements with a certain initial order in a certain time, you can specify that in a test (some testing frameworks support performance test, e.g. AUT). Bubble sort might fail that test. So what? That's the reason why we write tests first. We want to see it fail so we can fix it.

Because we have all the nice tests in place that test the external, non-temporal behaviour we can go and read about sorting algorithms and eventually throw out all that bubble sort code in favour of quick sort. Our tests will find out if we made a mistake. We will know if we break something and our latest test tells us if the chosen algorithm is fast enough for our requirements.

The test might even tell us that bubble sort is good enough. Why waste time on a super efficient algorithm if you need to sort a small number of items that are usually in order, but sometimes a new element is added to the list our of order. Bubble sort does that in one pass. You wont need quick sort, if the average number of items is 10.

Oh, by the way: You don't want to be caught committing premature optimization anyway, do you?

Large font for code editors

Submitted by Eric Schäfer on Wed, 07/29/2009 - 09:00

People always talk about how to gain screen real estate for their IDEs/code editors in order to have more code visible. Why do we need to have lots of code on the screen? What’s the benefit? Do I need to see more than the function I am currently working on? Not really.

About a month ago I set the font in all my editors to Consolas 12. This leaves me with just 45 lines in plain editors and about 30 in IDEs with a panel at the bottom. But that’s stupid isn’t it? With a 30” screen and a 9pt font you can get about three gazillion lines of code displayed. I will tell you a secret. If you keep your functions small and tidy you wont need more than 30 lines. Try it yourself. It helps keeping focused at the job at hand.

Implicit Type Parameter for Implementing Type

Submitted by Eric Schäfer on Fri, 04/24/2009 - 09:00

A while ago I had an interesting twitter discussion with Chris Ammerman (@cammerman) about type parameters of generic interfaces (C#). Chris tweeted "I often encounter a situation where I want a generic interface, but the type param should ALWAYS be the type of the implementing class". One example of this is ICloneable. Would it ever be acceptable for ICloneable.Clone() to return an object of a type other than the implementing type of the interface? With ICloneable you will always want to cast the result of Clone() because most of the time you want The Real Thing® instead of System.Object. For that reason many people create their own generic interface:

public interface ICloneable<T>
{
T Clone();
}

public class Foo : ICloneable<Foo>
{
Foo Clone() { /* implement me */ }
}

This is still ugly. I want this instead:

public interface ICloneable
{
implementer Clone();
}

public class Foo : ICloneable
{
Foo Clone() { /* implement me */ }
}

implementer would be a keyword like base or this but it would not refer to an object but to a type. It would behave as an implicit type parameter to the interface. This would not only be convenient syntactic sugar. It would also make the use of the parameter explicit. You couldn't do class Foo : ICloneable<Bar> anymore.

List of Tweets:

Syndicate content