When I’m writing technical docs in MS Word (an unfortunate day-job-related requirement) one of the things that can be annoying it the fact that it ‘helpfully’ converts straight quotes into curly quotes, even in code samples and other places that it shouldn’t. The easy way to get rid of this is to hit undo (⌘-z) immediately after typing the quote, this will undo the auto-correction but leave the actual quote character in place.

> I could end the deficit in 5 minutes. You just pass a law that says
that anytime there is a deficit of more than 3% of GDP all sitting
members of congress are ineligible for reelection.

He’s talking about the US Congress, but it would work here as well.

Excellent… The Power of Words.

Hat tip: fuadm.

To achieve great things, two things are needed, a plan and not quite
enough time.

Hat tip: Capitalists @ Work.

Martin Fowler has a new bliki entry talking about flag arguments, defined as:

A flag argument is a kind of function argument that tells the function to carry out a different operation depending on its value.

And, as an example of this API style:

1
2
3

Class Concert {
  public Booking book(Customer aCustomer, boolean isPremium);
}

And his preferred API design:

1
2
3
4

Class Concert {
  public Booking bookRegular(Customer aCustomer);
  public Booking bookPremium(Customer aCustomer);
}

The problem with this, as Mr. Fowler points out, is that it can lead to problems with the implementation. His preferred solution is to have a private implementation method exactly like the original problematic API:

1

private Booking bookImpl(Customer aCustomer, boolean isPremium)

But if we think about the problem for a little longer we can see that there is a better option available to us. The real problem with flag arguments is that they lose information at the call site, so the original example method would be called like this:

1
2
3
4

. . .
myConcert.book(poorCustomer, false);
myConcert.book(richCustomer, true);
. . .

There’s nothing to say what those true and false arguments actually mean. We can just define a type-safe enum to use instead of the boolean, that way the information is still present at the call site. This was our API becomes:

1
2
3

Class Concert public {
  enum TicketType { REGULAR, PREMIUM }
  public Booking book(Customer aCustomer, TicketType ticketType)

And at the call site:

1
2
3
4

. . .
myConcert.book(poorCustomer, TicketType.REGULAR);
myConcert.book(richCustomer, TicketType.PREMIUM);
. . .

This is easier to implement, and works for multi valued (e.g. integer) flags as well.