Achieving Code Symmetry

In my review of Kent Beck’s latest book, Implementation Patterns, I didn’t mean to present it as completely useless. It has some great points sprinkled throughout. It’s just that they are buried in trivialities. Still, one valuable concept Beck talks about in his book is that of code symmetry.

“Symmetry in code is where the same idea is expressed the same way everywhere it appears.”

Beck gives the following example:

void process () {
  input ();
  count++;
  output ();
}

The second statement is an implementation detail. It’s the how, not the why. For better symmetry, you can rewrite it as follows:

void process () {
  input ();
  incrementCount ();
  output ();
}

A little better. Whereas input() and output() are named after intentions (the why), incrementCount() is named after an implementation (the how).

An even better rewrite would yield this:

void process() {
  input ();
  tally ();
  output ();
}

Another problem with the first sample is that it jumps from one abstraction level to another.

“Code like this is jarring to the reader. Code is easier to understand when it flows, and abruptly shifting abstraction levels breaks flow. What is that bit twiddling in there? […] What does it mean?”

Explaining messages

Explaining message is a “pattern” in Beck’s book that is similar to the principle of code symmetry. He cites the following Smalltalk example:

highlight (Rectangle area) {
  reverse (area);
}

Come to think of it, the name highlight expresses the intention while reverse expresses the mechanics. Why does this matter?

“The distinction between intention and implementation has always been important in software development. It is what allows you to understand a computation first in essence and later, if necessary, in detail. You can use messages to make this distinction by sending a message named after the problem you are solving which in turn sends a message named after how the problem is to be solved.”

The highlight method above is an example of an explaining message. Even if it’s a one-liner, the “main purpose in invoking an explaining message is to communicate my intention more clearly.”

After all, the compiler doesn’t care how you name methods or format code. You’re writing it to communicate with other people. And that’s what Beck’s book is about.