I just finished reading Kent Beck’s Smalltalk Best Practice Patterns. Not because I’m about to start programming in Smalltalk – it would be an interesting language to experiment with, but I’m way too busy for that right now – but because I really wish I could program like Kent Beck.

This book had a couple of striking examples along those lines. One way that he suggests using the book (not the only way, just one way) is this: every time you are about to do something, you should look in the book for a relevant pattern (unless you know it already), and use it. Which might sound ridiculous if your only exposure to patterns is the Gang of Four book, but Beck presents many many more patterns, going down to a much lower level: he has patterns (or “patterns”, since I’m not sure everybody would agree that’s an appropriate label for them) covering such matters as variable naming and indentation. (He doesn’t insist that everybody agree with him on how to indent; he does think, and I agree, that it’s useful for a team to be consistent on such trivial issues.)

The point here is that he’s very successfully weaved his patterns into a pattern language covering a large amount of ground: if you have a basic idea of what to do in the large, then there’s a pattern that’s applicable, and that pattern in turn calls on smaller patterns for its implementation, which call on still smaller patterns. The theory (which I believe) is that, one you have a pattern language internalized, you can produce quite good code without having to think about it too much most of the time, allowing you to devote your brain cells to decisions where more thinking is necessary. You can see an example of this with larger scale patterns in his and Ralph Johnson’s article “Patterns Generate Architecture” in Kent Beck’s Guide to Better Smalltalk.

The other part in the book that made me say “man, I wish I could program like this” was the following bit from Method Comment:

Someone recently asked me point blank, “What percentage of your methods have comments?” I answered, “Between 0 and 1 percent.” Oh the uproar! As a sanity check, I asked a developer at one of my clients (where I had taught Smalltalk based on an earlier version of these patterns) what percentage of the methods of their 200 class system had comments. His answer, “between 0 and 1 percent.” “Has that ever been a problem?” “No, never.”

I just wish my methods were so transparent… I remember reading the refactoring book and coming across the place where Fowler says that comments are a sign of bad code. My first reaction was “that’s ridiculous!”. And, of course, if code is unclear, comments are a good thing; but what’s even better is to take the comments as a sign that the code needs to be refactored to make it clear, at which point the comments are probably no longer necessary.

One other predictor of bad code in Beck’s book that I hadn’t seen before was to check rates of change: don’t have a method or a class or whatever with some stuff that changes all the time and other stuff that never changes. A few days after reading that, I had a chance to apply it: I’m trying to refactor a ridiculously large class (something like 25 member variables, a constructor with about 10 arguments, etc.), and I noticed that some variables (corresponding to MPEG headers, basically) were basically set once and never changed. So I pulled some of them out into a class (a coworker wisely suggested that I not pull out all of them at once: pull out the elementary stream headers into once class, and pull out the transport stream headers into another class later), and sure enough, once I’d done that, I noticed that several methods in the original class only used those member variables and could easily be moved to the new class, and those were the only methods that accessed most of the member variables. By the time I was done I’d removed five or six member variables and two constructor parameters from the original class, had a delightfully small, self-contained, and testable new class, and was much happier with life. Of course, I could have been led to this refactoring through other routes (e.g. noticing that the variables in question were used together in certain methods), but the “rates of change” heuristic worked just fine.

Post Revisions: