Pleasant, unpleasant thoughts!

My cool code snippet

Sat, 22 Aug 2009 00:06:18 -0400

I submitted this to the Resharper cool code snippet competition and thought I would share it with everyone else, including why it’s cool!

[Test]
public void $METHOD$_$SCENARIO$_$EXPECTATION$()
{
$END$
}

I’ve been doing a lot of TDD lately and I am constantly writing new tests. So my number one snippet is one that creates a simple test. I’ve tweaked this template a lot, it started out with a simple test template with only one editable occurance for a name. In “The Art of Unit Testing,” Roy Osherove talks about test readability which starts with the test name itself. He suggests putting the test method name together with three components. First, name the method under test (the Act in AAA), that way related tests for the same method are easy to identify (and actually R# sorts test fixture test methods by name so this is even more useful with Code Cleanup :) ). Second, name it with a scenario, what is unique about the given context of the test (known as the Arrange in AAA). Finally, include the outcome of the test, the expectation (Assert in AAA). This way you know all of what will go into the test before you write it!

I gave his naming scheme a try and found out it offers a pit of success. If you cannot name these three parts then your test likely won’t be readable. Anyone should know what a test does without reading it, like with any method, it should be intention revealing! Without identifying a scenario explicitly, it may be blurred in several lines of setup (Arrange). Having the scenario in the name makes it explicit and makes me keep it simple (I hate long method names). The test may have too many expectations, again, I hate long method names so if I find myself putting multiple expectations in the name I will quickly realize I need to move the other expectations to new tests (SRP with testing)!

The same day I tried using this test method naming convention, was the same day I created this test snippet and have kept it ever since. Every time I write a test, I am very explicit and careful, which is very important with TDD, not to take on too much with any one test!

This snippet is awesome, not because of the code it creates, but because it sets myself up for success every time I use it, like having Uncle Bob Martin watching over my shoulder :)

Outlook 2010 + Google Cal Sync hack

Thu, 06 Aug 2009 01:58:00 -0400

So yeah Google Cal Sync doesn’t work with Outlook 2010 Preview, but I found a way to get it to jive.

I edited Outlook.exe in C:\Program Files\Microsoft Office\Office14 using Notepad++ with the Hex-Editor plugin. At assembly location 0x000c09b2, I changed the value to 0x32, in the ascii dump. It originally read (14.0.0 and now reads (12.0.0

Good luck, I have no idea what this might break, I hope it is just the outlook version that the add in manager reports to add ins :). I have successfully synced events to and from my GCal!

-Wes

"If you are doing custom Linq to Sql mappings, it currently doesn’t support having your own..."

Tue, 04 Aug 2009 17:58:01 -0400

“If you are doing custom Linq to Sql mappings, it currently doesn’t support having your own base Entity class that you extend all your entities from. I found out the hard way through painful debugging. However, it seems if you do this with the version of .net 3.5 sp1 on the Win 7 RC it will work, so this may not be a bug forever!”

NUnit 2.5.1 framework with Silverlight 3

Fri, 31 Jul 2009 00:48:00 -0400

We’re doing some Silverlight development at work and I’m doing some off to the side. I like to stick with a familiar, proven unit test framework. NUnit 2.5.1. has some great new attributes to use during testing (actually these came out in 2.5) such as Timeout and MaxTime. To take advantage of them you have to have a version of NUnit compiled as a silverlight library or at least recompiled referencing the core of silverlight (system.dll and mscorlib versions 2.0.5.0).

In the spirit of continuing what a few other people have done, I have compiled the latest version of the NUnit framework into a SL library and want to make it available. The work of the following guys has helped me use NUnit up to version 2.4 and helped me get 2.5.1 going as well!

A nice template that included the SL framework version, if someone wants this updated please let me know and I can do that too, otherwise I’ll just post my dlls: http://weblogs.asp.net/nunitaddin/archive/2008/05/01/silverlight-nunit-projects.aspx

A set of instructions to port the framework to SL (I diverged on some of these, see below): http://www.jeff.wilcox.name/2009/01/nunit-and-silverlight/

Here is the list of changes and what didn’t make the cut:

BinarySerializableConstraint - SL core doesn’t have BinarySerializer
AssertionException, IgnoreException, InconclusiveException, SuccessException - cannot be serialized, SL core doesn’t have SerializationAttribute (goes along with BinarySerializer)
RequiresSTA and RequiresMTA attributes

How was this pulled off?

For both the nunit.framework and nunit.framework.tests I added new silverlight libraries and copied the links to the code that the respective projects already referenced. I also added a nunit.silverlight to drop in some of the following additional classes that are needed but not in the SL core.
I want to thank Jeff Wilcox for his original work on some shims
- ArrayList which I added a ToArray method that takes a type, of course this was ripped off of the ArrayList (via reflector) in the .Net core so someone should let me know if MSFT is going to come take away my computer for publishing this
- Hashtable
I added a ListDictionary which is just a version of the generic Dictionary class with key and value set to type object
String.Compare(string,string,bool) - a version of string comparison not included in the silverlight core, again thank you reflector
I made up an ApplicationException as this wasn’t in the SL core
I made a version of the non generic Comparer class that isn’t in the SL core, thanks reflector
I added the compiler directive NET_2_0
A lot of the functionality that was removed was done so by leveraging the SILVERLIGHT compiler directive to exclude the relevant code.

I also went into the framework tests and tweaked a new solution to work with silverlight. I had to modify the tests as follows:

CanTestContentsOfSortedList excluded - no SortedList in SL
Remove references and tests with System.Data types (NotGreaterEqualIComparable, NotGreaterIComparable, NotLessEqualIComparable, NotLessIComparable)
Remove SameColorAs constraint, which was only referenced by NamedAndUnnamedColorsCompareAsEqual, which was commented out anyways
Remove BinarySerializableTest and XmlSerializableTest tests that depend on Serializable attribute
Changed DifferentEncodingsOfSameStringAreNotEqual test to use System.Text.Encoding.UTF8.GetString(byte[],start,length) overload as (byte[]) overload isn’t available in SL
Removed CodeShouldNotCompile and CodeShouldNotCompileAsFinishedConstraint as Microsoft.CSharp.CSharpCodeProvider is not available in SL

So, altogether the changes were minimal and there are 1273 tests passing on the SL version of the framework!

To use these assemblies:

Setup a SL library as your test library.
Download the SL libraries here
Include a reference to the nunit.framework.dll.
If you have trouble getting tests to run (missing file exceptions to SL assemblies) then set “Copy Local: true” on the appropriate assembly reference in the properties. I always have to do this for the system SL assembly.

If anyone wants more source for what I did or more bits of the nunit framework (like mocks or w/e) ported, please let me know and I will get that done, if possible :) For now I’m happy with just the framework as I use Rhino.Mocks (which already has a SL port) as an isolation container.

-Wes

"Not using a ubiquitous language when developing an application is incurring yet another form of..."

Sun, 26 Jul 2009 16:19:47 -0400

“Not using a ubiquitous language when developing an application is incurring yet another form of design debt, the overhead involved in manual testing is similar to the overhead incurred in translating between separate languages when conversations between users/domain experts and developers occur. Like with foreign languages, idiomatic assumptions and other misunderstandings are likely to fall short of a true conversation, so just pony up and focus on using a COMMON LANGUAGE as Eric Evans refers to in DDD.”

- Me

Null Object Pattern

Tue, 21 Jul 2009 18:40:00 -0400

Code reuse is very important for developers, most of the patterns and refactorings exist soley to reduce the smell of duplicated code. Null checks are one of the biggest culprits of duplicated code. It is also, to a degree, a concern that often gets scattered through out an application and isn’t properly separated. Without testing and/or good documentation, it’s often hard to determine the expectations of a method that returns a reference type or a nullable value type. Often, unnecessary, paranoid, null checks are incorporated to deal with the problem. The null object pattern almost solely exists as a pattern to reduce code, so if it cannot reduce the amount of code you are writing, don’t use it! The idea is that instead of setting a refernece type to null initially, you set it to an implementation of the type that executes “null behavior” if methods are called on it’s contract that would normally throw a null reference exception.

Pros

Redcue code
Separated concerns when handling null logic

Cons

Not familiar to newer developers
Can complicate code, make sure it is actually reducing the amount of code before implementing! This is not a pattern to start with in a standard toolset!

Say we have a contract for a type:

	public interface IThing
	{
		void Do();
		bool Execute();
	}

and your system made a large number of calls to this Do method but had to check if the Thing was null before calling Do/Execute, you could replace the initial value of a reference to it with a Null implementation instead, then if someone calls a method on a null instance it won’t have any side effects (including null reference exceptions) if it wasn’t initialized already.

	public class NullThing : IThing
	{
		public void Do()
		{
			
		}

		public bool Execute()
		{
			return true;
		}
	}

Then, anywhere that used this type could initilize to the NullThing:

	public class ThingHaver
	{
		private IThing _Thing = new NullThing();
		public IThing Thing
		{
			get
			{
				return _Thing;

			}
			set
			{
				_Thing = value;
			}
		}
	}

What would be really cool is if we could somehow overload the default operator in c# and set what it returns. Then, if we used an abstract base class of IThing (ThingBase), we could implement this to return our NullThing(), assuming that behind the scenes the compiler relied on wiring up calls to default whenever it ran across:

private ThingBase _Thing;

Then we wouldn’t even have to set our variable to NullThing! Though maybe I’m getting too far off on a tangent here :) My one concern with this pattern is that it is very easy to produce a disparity in a team if they all aren’t aware of the pattern or it’s implementation in a particular scenario. -Wes

"Program to an interface, not to an implementation"

Sat, 20 Jun 2009 18:41:57 -0400

““Program to an interface, not to an implementation””

- Not sure if this has a source, but it’s a great concept.

Refactoring - Compose Method

Thu, 18 Jun 2009 00:22:00 -0400

This refactoring, again from Refactoring to Patterns, reduces ambiguity in methods that have too much detail or conditional logic to quickly comprehend. By breaking a method down into smaller methods, the ambiguity can be removed.

The mechanics of this refactoring are rather subjective, but obviously lead to the use of Extract Method. Study the code and make sure you understand it, the longer this takes, the more you need to apply this refactoring! Clean up the code, look for unused or duplicated pieces. Then, extract detail to smaller methods. Reveal intention through naming of new variables and methods. Once you are done, make sure all the code in the Composed Method is of the same level of detail.

Pros

Readability
Uniform level of detail.
Joshua lists difficulty in debugging as a drawback, however, I think a stack trace that points to the smaller, intentionally named method will increase the likelihood that I can figure out what is wrong before I even crack open the code!
Another benefit to add to Joshua’s list: code re-use of the extracted methods to replace other duplicated code.

Cons

Excessive quantity of small methods, though Joshua points out this could lead to applying Extract Class.

So I rummaged around in some code and stumbled upon a text box validation method that was a great candidate for this refactoring:

public virtual void Validate()
{
	IsValid = true;
	if (Visible && Enabled)
	{
		if (IsRequired)
		{
			if (String.IsNullOrEmpty(Text) || Text.Trim().Length == 0)
			{
				ErrorMessage = String.Format(Messages.TextBoxCannotBeEmpty, InvalidDisplayName);
				IsValid = false;
			}
		}

		if (MaxLength != 0 && !String.IsNullOrEmpty(Text) && Text.Trim().Length > MaxLength)
		{
			ErrorMessage = String.Format(Messages.TextBoxExceedsMaximumLength, InvalidDisplayName, MaxLength);
			IsValid = false;
		}

		if (MinLength > 0 && (String.IsNullOrEmpty(Text) || Text.Trim().Length < MinLength))
		{
			ErrorMessage = String.Format(Messages.TextBoxUnderMinimumLength, InvalidDisplayName, MinLength);
			IsValid = false;
		}
	}
}

The level of nested conditionals makes it rather hard to follow. First, I want to remove some of the nesting by returning immediately if the validation isn’t applicable:

public virtual void Validate()
{
	IsValid = true;
	if (!Visible || !Enabled)
	{
		return;
	}
	if (IsRequired)
	{
		if (String.IsNullOrEmpty(Text) || Text.Trim().Length == 0)
		{
			ErrorMessage = String.Format(Messages.TextBoxCannotBeEmpty, InvalidDisplayName);
			IsValid = false;
		}
	}

	if (MaxLength != 0 && !String.IsNullOrEmpty(Text) && Text.Trim().Length > MaxLength)
	{
		ErrorMessage = String.Format(Messages.TextBoxExceedsMaximumLength, InvalidDisplayName, MaxLength);
		IsValid = false;
	}

	if (MinLength > 0 && (String.IsNullOrEmpty(Text) || Text.Trim().Length < MinLength))
	{
		ErrorMessage = String.Format(Messages.TextBoxUnderMinimumLength, InvalidDisplayName, MinLength);
		IsValid = false;
	}
}

Next, I notice 3 different “sub validations” occurring. One validates if the field is required, the next validates the maximum length and the last validates the minimum length. Each of these can become their own methods:

public virtual void Validate()
{
	IsValid = true;
	if (!Visible || !Enabled)
	{
		return;
	}

	ValidateRequired();
	ValidateMaximumLength();
	ValidateMinimumLength();
}
private void ValidateRequired()
{
	if (IsRequired)
	{
		if (String.IsNullOrEmpty(Text) || Text.Trim().Length == 0)
		{
			ErrorMessage = String.Format(Messages.TextBoxCannotBeEmpty, InvalidDisplayName);
			IsValid = false;
		}
	}
}
private void ValidateMaximumLength()
{
	if (MaxLength != 0 && !String.IsNullOrEmpty(Text) && Text.Trim().Length > MaxLength)
	{
		ErrorMessage = String.Format(Messages.TextBoxExceedsMaximumLength, InvalidDisplayName, MaxLength);
		IsValid = false;
	}
}
private void ValidateMinimumLength()
{
	if (MinLength > 0 && (String.IsNullOrEmpty(Text) || Text.Trim().Length < MinLength))
	{
		ErrorMessage = String.Format(Messages.TextBoxUnderMinimumLength, InvalidDisplayName, MinLength);
		IsValid = false;
	}
}

Finally, I realize the level of detail isn’t uniform, I should extract a new property to check if the control is in use. Also, even more troublesome, the intentions of the first line to set the IsValid to true are lost to future developers. This is needed to reset the validation process, otherwise if a control is validated and fails, subsequent calls may still return invalid. My new Composed Method finally becomes:

public virtual void Validate()
{
	ResetValidation();
	if (!InUse)
	{
		return;
	}
	
	ValidateRequired();
	ValidateMaximumLength();
	ValidateMinimumLength();
}
private void ResetValidation()
{
	IsValid = true;
}
private bool InUse
{
	get
	{
		return Visible && Enabled;
	}
}
...

The new Composed Method is much easier to comprehend. Ironically enough, looking at other validation methods, the newly extract methods can be re-used either through inheritance or possibly by applying Extract Class. The new InUse property may eventually be exposed for public consumption.

Chain Constructors

Wed, 17 Jun 2009 22:52:00 -0400

Chain Constructors is another refactoring from the book Refactoring to Patterns, it helps remove duplication in constructor overloads. This should be a very familiar refactoring for most developers. Catch all constructors are produced, and hopefully minimized, that other constructors rely on either directly or indirectly. Mechanics

Study the constructors in the class and find the two with the most shared code. Say I have two constructors to create lines as follows:

public class Line
{
	...
	private Line()
	{
		Style = LineStyle.Solid;
		Color = LineColor.Black;
		Thickness = 1;
	}

	private Line(LineStyle style, LineColor color, int thickness)
	{
		Style = style;
		Color = color;
		Thickness = thickness;
	}
	...
}

These can be chained together, to reduce redundant code and leave a common spot for future property initializations.

public class Line
{
	...
	private Line()
		: this(LineStyle.Solid, LineColor.Black, 1)
	{
	}

	private Line(LineStyle style, LineColor color, int thickness)
	{
		Style = style;
		Color = color;
		Thickness = thickness;
	}
	...
}

Repeat step one, even with constructors already chained, to maximize chaining and code re-use.
Re-scope any constructors that no longer need to be public.

Pros

Code reuse
Avoid future mistakes when new code in one constructor isn’t copied to others.

Cons

Highly nested constructors might become confusing, try to keep it simple, if you find many levels of chaining, you may want to consider applying refactorings to or twoards Creation Method and/or Factory patterns to help reduce ambiguity

Refactoring, Creation Methods

Wed, 17 Jun 2009 01:46:00 -0400

Lately, I’ve been engulfed in several design books, one of which is Refactoring to Patterns by Joshua Kerievsky. The book is an extension of Martin Fowler’s book, Refactoring. It emphasizes learning to use patterns by working with existing code, identifying code that “smells” and then finding a pattern to refactor the code “to, towards or away from.” Smelly code typically involves duplication, complexity and/or ambiguity.

Joshua believes, rather than heavy pattern use up front, to let code evolve into or away from patterns. I thought it might be fun to share some of these refactorings and examples from my code past (gasp).

One of the first refactorings, Replace Constructors with Creation Methods. Simply put, when we have lots of overloads or parameters for our constructor(s), ambiguity arises as to the intended use. Often we add conditional plumbing to construct different instances of the same class with different run time behavior. The problem is that the constructors are called the same way and we have no way of providing intention through naming conventions like we can with methods and other members.

I went back to some old code and found an example of where this refactoring could help. The code was doing various types of charting by abstracting the creation of lines to separate instances before rendering the chart. One of the classes, scrubbed, had constructors as follows:

public class Line
{
	...
	public Line(int year, int month, int productId)
	{
		Initialize(year, month, productId);
		LoadData();
	}

	public Line(int month, int productId)
	{
		Initialize(2000, month, productId);
	}
	...
}

The first overload has an extra parameter to provide the year, that is all a user of this class would see when they come across instantiations of this class. With out digging deeper they wouldn’t realize that one overload queries and loads actual data points for the specified product while the other was intended to provide a way to manipulate and map existing lines to new lines.

The refactoring seeks to use methods to create instances of the class and subsequently, if appropriate, hiding the original constructors so users are forced to use the new, hopefully less ambiguous, Creation Methods.

Every refactoring has a set of steps, which should be performed one at at time until the desired changes are complete. Joshua emphasizes that not all steps must be completed. Sometimes only part of a refactoring is sufficient to clean up smelly code.

The “Mechanics,” as Joshua refers to in his book, are as follows:

Find a spot where the class is instantiated and apply the refactoring Extract Method.

Line line = new Line(2009, 2, productId);

Refactors to (note the extracted method should be static):

Line line = CreateLine(2009, 2, productId);
...
public static Line CreateLine(int month, int year, int productId)
{
	return new Line(month, year, productId);
}

Next, apply Move Method and move the new method to the class it instantiates.

Line line = Line.CreateLine(2009, 2, productId);
...
public class Line
{
	...
	public static Line CreateLine(int month, int year, int productId)
	{
		return new Line(month, year, productId);
	}
	...
}

Find all code that uses this specific constructor, for this specific intended use, and refactor it to use the new Creation Method. Be careful to check for constructors that are used for several different intended purposes, these should be broken out into their own separate Creation Methods. Red flags for this include conditional logic in the constructor and/or allowing null/default values for a parameter that drive different class behaviors.
Joshua mentions to repeat steps 1 to 3 for all other constructor overloads. I’d rather switch his last two steps. So, in this step, make any constructors that are no longer publicly used, private or internal to avoid users trying to call the constructors. Remeber, each step is optional, and in some cases you may not want to re-scope the constructor.
```
public class Line
{
	...
	private Line(int year, int month, int productId)
	{
		Initialize(year, month, productId);
		LoadData();
	}
	...
}
```

Repeat for all applicable constructors. To save time, I will show the final form of my Line class:

public class Line
{
	...
	private Line(int year, int month, int productId)
	{
		Initialize(year, month, productId);
		LoadData();
	}

	private Line(int month, int productId)
	{
		Initialize(2000, month, productId);
	}

	public static Line CreateLine(int month, int year, int productId)
	{
		return new Line(month, year, productId);
	}

	public static Line CreateMappingLine(int year, int productId)
	{
		return new Line(year, productId);
	}
	...
}

It is easy to see how the intentions of the different constructors are present in the names of their Creation Methods. The second overload’s Creation Method now clearly creates a mapping line whereas the first creates an actual line. This helps the developer avoid assumptions when reading the client code!

Joshua lists pros and cons for each refactoring. For this refactoring, the positives are that we can express intentions and increase the readability/maintainability of our code. Also, in cases where a single constructor creates two instances that behave differently, we can get around this by using the exact same parameter set but showing the intended differences in the Creation Method names. Whereas with constructors we can only have one constructor per parameter set. Finally, a word of caution, using Creation Methods is rather non standard. I would personally, and Joshua hints at it too, use some type of Factory/pattern with this instead of just a Creation Method. I feel that developers are likely to be familiar with the Factory/pattern(s) and know to look for that when constructors are missing, at least more so than Creation Methods.
Happy Coding!