Over the past several months I’ve become a huge Sandi Metz fanboy, as my teammates can attest. Her Practical Object-Oriented Design in Ruby: An Agile Primer has significantly changed the way I write code.

In her book, Sandi gives some guidelines for writing code that allows for easy changes. She suggests that code should be TRUE:

  • Transparent: The consequences of change should be obvious in the code that is changing and in distant code [that] relies upon it.
  • Reasonable: The cost of any change should be proportional to the benefits the change achieves
  • Usable: Existing code should be usable in new and unexpected contexts
  • Exemplary: The code itself should encourage those who change it to perpetuate these qualities

These are all great guidelines, but I want to focus on the last one: Exemplary. This was an epiphany for me, and I think the idea needs wider publicity.

Until I read this book, I had never thought of the idea of exemplary code.

If someone on my team were to use the code I just wrote as a model for some new code they’re working on, would that be a good thing? Did I use a design that should be propagated throughout the system? Or did I take a shortcut that should not be repeated?

In my recent work, I’ve been trying to make the idea of exemplary code explicit in my decision-making. I ask myself or my pair, “Is this code exemplary? Do I want my teammates to follow the approach I took here? Will it encourage the maintenance of a good design as the code evolves? If someone needs to add a new feature here, will it be obvious how to do it cleanly? “ If the answer is “no” to any of these questions, then I know I’m not done yet.