About five years ago, I was visiting a company on the east coast and I sat with one of their developers. We were about to make some changes in a method that was a couple hundred lines long and I said “Let’s break this method down a bit; let’s do some extractions.” The developer looked at me and said “Oh. You’re an academic.”

I don’t think I’ll ever forget that incident. I knew that I probably wouldn’t get much mileage out of saying “Hey, the best programmers I know would say that this method is ridiculously long, if you don’t see it that way, I don’t know what to say.” So, we worked together for a while and it snuck up on him. We got to a point where it was obvious that we had to do something different, and sure enough it was extract method.

The fact is I didn’t have the heart to tell him that it was a bit worse than he thought. I’m not an academic, but I do like to factor my code to a very fine grain. I like to break methods down into itty bitty pieces so that every single one of them does exactly one thing. They’re one to five lines, ten or twenty lines max; and, in my opinion, they’re beautiful.

Here’s an example. I was writing a utility a while ago that produces specialized source code wrappers for classes in java libraries. As I was working on it, I noticed repetitive formatting. I pulled it out into a class and this is what I ended up with:


package glaze.tool;

public class Formatter {
	private String text = "";
	private String indentation = "";

	public void newLine() {
		newLine("");		
	}
	
	public void newLine(String lineText) {
		newText("\n" + indentation + lineText);		
	}
	
	public void newText(String newText) {
		text += newText;
	}

	public void indent() {
		indentation += "\t";
	}

	public void outdent() {
		if (indentation.length() > 0)
			indentation = indentation.substring(1);
	}	

	public String getText() {
		return text;
	}
}

The methods are ridiculously small but they form a little language that reads rather well in code. Here’s an example of its use:


package glaze.tool;

import java.lang.reflect.Method;

public class GlazeInterface extends GlazeType {
	private final static String INTERFACE_NAME_PREFIX = "I";

	public GlazeInterface(Class clazz, ClassStore store) {
		super(clazz, store);
	}

	@Override
	protected void buildDeclaration() {
		out.newLine("public interface " + getName() + " {");
		out.indent();
		buildMethods();
		out.outdent();
		out.newLine("}");
		out.newLine();
	}
	
	protected GlazeMethod makeGlazedMethod(Method method) {
		return new GlazeInterfaceMethod(method, store);
	}
	
	public String getName() {
		return INTERFACE_NAME_PREFIX + wrappedClassName();
	}
}

Now, if you’ve encountered code like this before, code where all of the methods are very short, you might have cursed the person who wrote it. It looks overfactored, but is it? Most of the methods ended up this small because I was very zealous about removing duplication, and it’s hard to argue for duplication. On the other hand, I have to admit that the code is a bit opaque. It takes time and study to see how the pieces fit together, but once you understand, changes are often easier and you don’t have to touch as much code to make them.

I spend a lot of time helping people in ugly sprawling code, so it's nice when I get a chance to factor code finely. I don't think I'm alone. I've seen a number of examples of this coding style over the years.. a Java port of the HotDraw framework, an early version of emacs, various implementations of the STL in C++.

If you haven't taken a piece of code and tried to squeeze out every bit of duplication, try it as an experiment. See what happens.