Agile Mind Tricks

High code coverage + low cyclomatic complexity = quality code.

2008-06-10T14:37:00.000-07:00

I have often heard and agree with the statement that 100% code coverage does not guaranty quality code. However, if you also monitor cyclomatic complexity of your code you will greatly increase the probability that it is problem free. If any method does not have 100% coverage or has cyclomatic complexity greater that 7 it should be suspect. The tool that I currently use for cyclomatic complexity is Code Monitor www.campwoodsw.com/sourcemonitor.html

Debugger Driven Development

2008-01-11T14:04:00.000-08:00

I have just discovered a new way of doing TDD and I am calling it Debugger Driven Development.

This is how you do Debugger Driven Development.
1) Write a test which calls some method that does some complex calculation.
2) Add an assert statement with a null expected value.
3) Run the test in the debugger get the actual value returned by the method and use it for the expected value.

Debugger Driven Development is just so wrong. It does have some value for regression testing assuming your code is correct but it will cause big problems if it's incorrect. What you should do is always calculate the expected value by hand. That way if the value returned by your program matches your hand calculation their is a high probability that your code is correct. Doing Debugger Driven Development proves nothing.

Encapsulate complicated or generic code

2008-01-11T13:23:00.001-08:00

Whenever you come across code that is more complex or generic than it needs to be try to refactor it. However it may not be possible to do this in some cases. When that happens just wrap the complex code with your own class that has the interface that you wished you had to work with.

Here is an example

The following code calls gateway.GetProducts(criteria) to return an array of products. Notice that most of the code below is just used to set up the criteria object.

ICriterion salesDateCriterion = new SalesDateCriterion(newstring[]{uploadDate.ToString()},
OperationEnum.Equal);
ICriterion prodLineIdCriterion = new ProdLineIdCriterion(new string[]
{productionLineId.ToString()},OperationEnum.Equal);
ICriterion productNoCriterion = new ProductNoCriterion(productNo.ToString(),
OperationEnum.Equal);
ICriterion[] criteria = new ICriterion[] {salesDateCriterion, prodLineIdCriterion,
productNoCriterion};

IProduct[] products = gateway.GetProducts(criteria);

if (products.Length != 1 || products[0] == null)
throw new Exception("Product not found");

return products[0];

For my application I did not need the power that criteria gave me I only needed to find a single product by uploadDate, productionLineId and productNo. So I just wrapped the above code in a method called GetProduct. Now the client code now contains a single line of code that is much easier to understand.

public IProduct GetProduct(UploadDate, productionLine,productNo)

In the newly created class I also added two similar methods GetVariety and GetOrder.

public IVariety GetVariety(int varietyNo)
public IOrder GetOrder(DateTime uploadDate, int productionLineId, int productNo)

Microsoft Advertising Ruby On Rails.

2007-12-05T07:41:00.000-08:00

Today I went to Microsoft’s ASP.Net website and was surprised to find it advertising Ruby On Rails.

"Experience the latest release of the most productive and powerful development tool and user interface platform on the planet."

However those guys at Microsoft screwed up the images and download link. The download link pointed to ASP.NET 3.5 instead.

IThis, IThat, ITheOther

2007-11-23T07:29:00.000-08:00

I have seen projects where every class had implemented an interface by default. The interfaces always had the same names as the classes except they were prefixed with an (I). I don't call this good design. The flexibility that an interface gives you has a cost. If an interface is not paying for this cost it should be removed. Only use interfaces when the flexibility is required. It is often difficult to tell in advance where this flexibility is needed so it is usually best to add an interface when the flexibility is required. Also instead of using the (I) prefix I prefer to name the interface by how the client will use the class. So instead of creating and IBook interface for a Book class, I could create a Readable interface instead. Removing the last trace of Hungarian notation from my code.

Singleton Anti-Pattern

2007-11-21T10:22:00.001-08:00

The Singleton pattern is probably the most over used design pattern there is. Singletons are the same as global variables and make object collaboration less visible. They violate the Single Responsibility Principle mixing an object with its creation logic. They also create difficult to test code because they bind you to the exact type of the Singleton object and Singletons persist state causing test order to be dependent.

A Singleton object should be rarely used and when used it should be only used to solve a performance issue or as a last resort when parameter passing becomes very difficult.

What makes an excellent developer excellent?

2007-11-08T07:41:00.000-08:00

Is it his knowledge of C# or Java Syntax? Is it his knowledge of every corner of every obscure framework? I don't think so. It is important to know what is possible in a language or framework but you can always lookup the fine details when you need to.

This reminds me of a story of when one of Einstein's colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. "You don't remember your own number?" the man asked, startled. "No," Einstein answered. "Why should I memorize something I can so easily get from a book?"

It is the developer’s knowledge of good object oriented design principles and domain modeling that makes a great developer stand out. If you are not strong in these areas it will be very difficult for you to Google them as you go.

Replace With Direct Cast

2007-11-06T14:07:00.001-08:00

An instance of the as operator should always be followed by a check against null.

Customer customer = obj as Customer;

if(customer != null){
customer.Update();
}

If you don't want to check against null than refactor to a direct cast.

(obj as customer).Update;

If the direct cast fails you will get an InvalidCastException instead of a NullReferenceException which will be easier to diagnose.

Remove Unneeded Property

2007-11-05T13:43:00.000-08:00

If you have a property that looks like the following just remove it. It is not adding any value.

public string PositionTitle
{
get
{
return this.positionTitle;
}
set
{
this.positionTitle = value;
}
}

Refactoring tools such as Resharper make encapsulating a field simple. So you can always refactor to the property later if you find that you need it.

Now doesn't the following code look so much nicer?

public string positionTitle;

Replace multidimensional if condition with double dispatch.

2007-10-24T06:58:00.000-07:00

If you have a series of if conditions that vary in two dimensions it may be possible to replace the conditionals with double dispatch.

public class passenger
{
public Vehicle vehicle;
public string type;
public void travel()
{
if (vehicle.Type == "Car")
{
if (this.Type = "Rich")
{
RideInLimo();
}
else if (Passenger.Type = "Poor")
{
Drive();
}

else if (vehicle.Type = "Airplane")
{
if (this.Type = "Rich")
FlyInPrivateJet();
else if (Passenger.Type = "Poor")
{
FlyCoach();
}

}
}
}
}

In the above example the first refactoring that I would like to apply is Replace Type Code with Class. However the way a person travels does not only depend on the type of vehicle he uses but also the type of person they are as well. This problem can be solved by passenger passing itself as a parameter to the vehicle class. Then the vehicle class can use method overloading to create to versions of the travel method for each type of person.

Here is the refactored code.

public class Passenger
{
public Vehicle vehicle;
public void Travel()
{
vehicle.Travel(this);
}

}

public class Car : vehicle
{
public void Travel(RichPersion Passenger)
{
RideInLimo();
}
public void Travel(PoorPersion Passenger)
{
Drive();
}

}

public class Plane : vehicle
{
public void Travel(RichPerson Passenger)
{
FlyInPrivateJet();
}

public void Travel(PoorPerson Passenger)
{
FlyCoach();
}

}
One drawback of using this approach is that it violates the Open Close Principle because you will have to add a new version of the travel method on the vehicle object for each new person type that you add to your application.

Move Foreign Method to Server Class

2007-10-22T09:06:00.000-07:00

When I am working with code that is not object oriented I often see a bunch of objects that just contain data and not much behavior. These methods are often passed to helper classes that perform the real work.

Class MyHelperClass
{
public static void DoSomething(MyObject thing)
{
Dothis(thing.This);
Dothat(thing.That);
DoTheother(thing.Other):

}
}

Whenever I see static helper functions I look at the parameter list for objects that would be a better home for the function.

This specific instance of the Move Method refactoring is kind of the reverse of the Foreign Method refactoring. So my name for this refactoring is "Move Foreign Method to Server Class"

Fluent Constructors

2007-10-19T12:52:00.000-07:00

Something in the following code just does not look right to me.

Employee employee = new Employee();
employee.EmployeeNumber ="1565407"
employee.Name = "Nick"
employee.LastName = "Markovic"
employee.JobFunction = CreateJobFunction("Tester")

The Employee Constructor just tells me nothing on how to use the object.

It does not tell which properties are required and which are not.
In this example EmployeeNumber, Name and LastName were all required but JobFunction was not. To make things worse the employee object has about 20 other properties on it. I came across this problem while I was writing unit tests for legacy code and needed to create a simple employee to pass as a parameter. I had to go digging through the internals of employee to determine which fields needed to be set.
However if the creator of this class had crated a constructor that looked something like Employee(number,firstName,LastName). The interface would be much more fluent and would create much easier to understand code.

Strings - The only data type you will ever need.

2007-10-19T12:51:00.001-07:00

I have seen lots of code that looks like the following

Person candidate = CreatePerson()
string hireDate= "02/12/2005"
string departmentId = "12";
HirePerson(person,hireDate,departmentId)

I often see methods that take strings as parameters when they are dealing with values that should be stored in more expressive data types. Usually this happens with values that get pulled out of text boxes on the UI. These parameters start getting pasted all over the place and only end up getting cast to a more specific data type when some special functionality like date comparison is needed.I have also seen this happen with id values. They often get converted back and forth from int to string as they get passed around the application. I guess this code smell is kind of like primitive obsession taken to the extreme.