DevExpress Newsletter 32: Message from the CTO

This time, I start a two-part message. The first part is about writing small single-task methods:

The Composed Method pattern

One of the things I've adopted over the years in my own programming is the use of small methods -- that is, small as in few lines of code. It's made much easier by the use of a good Extract Method refactoring tool. In my case, that's CodeRush, and it's become second nature to apply Extract Method as I'm writing the code since there no cognitive friction in using it.

I was delighted to learn recently that this practice is known as the Composed Method pattern. It was first devised and promoted by Kent Beck in Smalltalk. In essence, there are three rules to the pattern:

   1. Divide your programs into methods that only perform one identifiable task.
   2. Keep all of the operations in a method at the same level of abstraction.
   3. This will result in programs with many small methods, each a few lines long.

Why do this?

Firstly: it's really easy to write unit tests for simple methods. The more testing you have the more confident you'll be that your application is good and will work both before and after maintenance.

Secondly: it's easier to read a small self-contained method and understand what it does. It's also easier to verify the code in your head, to deskcheck it if you like, increasing your confidence in the validity of the code.

Thirdly: in writing small methods, it's easier to give them understandable names. Once you have those, you make the code easier to read and avoid the need for comments -- and we all know that comments get stale and therefore meaningless.

Fourthly: in writing these small methods, we discover what's known as emergent design. The smaller the methods, the more likely we're going to spot opportunities for creating new classes that have distinct behavior and state. The design of the class model will emerge from our incremental coding.

That last point is extremely important for writing code in a TDD or BDD manner: let the design emerge from our exploratory coding. It's also very important if you're given a hunk of legacy code to maintain. Refactoring it to the Composed Method pattern and using emergent design lets you improve that legacy code and make maintenance easier.

All in all, I'd recommend you look at the Composed Method pattern and start writing small methods.

(You can see the video here.)

The other thing I didn’t mention is that, in .NET, small methods are more likely to be inlined by the JITter at run-time, and in some other languages you can provide hints to the compiler that a method can be inlined if necessary. So the excuse that “calling lots of small methods increases run time” is not necessarily true.

Which leads to another point I’ve made before: we should be writing code in such a way that other people can read and understand it, not for the compiler. After all, the compiler will correctly compile all kinds of badly-written code without complaint (I’m reminded of one app I had to maintain in my early days as a programmer: the original developer had used flower names for all his variables), but it’s the human programmer that has to read, understand, and debug it.

Part two will be available in a fortnight’s time in the next newsletter. SLAP!

Free DevExpress Products – Get Your Copy Today