A Square Is Not a Rectangle

Friday, September 11th, 2009

The following example, taken from an introductory text in object oriented programming, demonstrates a common flaw in object oriented design. Can you spot it?

public class Rectangle {

  private double width;
  private double height;

  public void setWidth(double width) {
    this.width = width;

  public void setHeight(double height) {
    this.height = height;

  public double getHeight() {
    return this.height;

  public double getWidth() {
    return this.width;

  public double getPerimeter() {
    return 2*width + 2*height;

  public double getArea() {
    return width * height;

public class Square extends Rectangle {

  public void setSide(double size) {


(I’ve changed the language and rewritten the code to protect the guilty.)

Why Pair Programming Works

Tuesday, June 30th, 2009

Pair programming is like magic in more ways than one. It dramatically improves programmer productivity and reduces bug count, and yet it does so through a technique that’s completely counter-intuitive. You can’t help but think that there’s some trick yet to be exposed; that pair programming is just slight of hand. In this article, I will endeavor to pull back the curtain and reveal the secrets of the pair programming magicians.

Specifically, I identify six reasons pair programming succeeds:

  • Continuous Code Review
  • Fewer blockages
  • Masking distractions
  • Guaranteed focus
  • Multiple points of view
  • Reduced training cost and time


Imagine There’s No Null

Wednesday, May 27th, 2009

A couple of weeks ago I spent a considerable amount of time chasing down bugs involving null in a large code base: null checks after a variable had already been dereferenced, nulls passed to methods that would immediately dereference them, equals() methods that didn’t check for null, and more. Using FindBugs, I identified literally hundreds of bugs involving null handling; and that got me thinking: Could we just eliminate null completely? Should we?

What follows is a thought experiment, not a serious proposal. Still it might be informative to think about it; and perhaps it will catch the eye of the designer of the next great language.

In Praise of Draconian Error Handling, Part 1

Monday, January 12th, 2009

I’m doing a bit of work on XOM, trying to optimize and improve some of the Unicode normalization code. A lot of this is autogenerated from the Unicode data files, and I’m actually working on the meta-code that parses those files and then generates the actual shipping code. In this code, I’m setting up a switch statement like this one:

       switch(i) {
          case 0:
            return result + "NOT_REORDERED";
          case 1:
            return result + "OVERLAY";
          case 7:
            return result + "NUKTA";
          case 8:
            return result + "KANA_VOICING";
          case 9:
            return result + "VIRAMA";
          case 202:
            return result + "ATTACHED_BELOW";
          case 216:
            return result + "ATTACHED_ABOVE_RIGHT";
          case 218:
            return result + "BELOW_LEFT";
          case 220:
            return result + "BELOW";
          case 222:
            return result + "BELOW_RIGHT";
          case 224:
            return result + "LEFT";
          case 226:
            return result + "RIGHT";
          case 228:
            return result + "ABOVE_LEFT";
          case 230:
            return result + "ABOVE";
          case 232:
            return result + "ABOVE_RIGHT";
          case 233:
            return result + "DOUBLE_BELOW";
          case 234:
            return result + "DOUBLE_ABOVE";
          case 240:
            return result + "IOTA_SUBSCRIPT";
            return result + "NOT_REORDERED";

And then I stop myself. Do you see the bug? Actually it’s a meta bug that leads to the true bug.

Prefer Multiline if

Thursday, January 1st, 2009

C-family languages including Java, C#, and C++ do not require braces around single line blocks. For example, this is a legal loop:

for (int i=0; i < args.length; i++) process(args[i]);

So’s this:

for (int i=0; i < args.length; i++) 

However both of these are very bad form, and lead to buggy code. All blocks in C-like languages should be explicitly delimited by braces across multiple lines in all cases. Here’s why: