Sandi Metz is one of my many role models in software development. Her book “Practical Object-Oriented Design in Ruby” is a must read for any programmer who wants to write better object-oriented code. It’s short, clear and to the point and it made me even more enthusiastic about writing clean and eloquent code driven by empathy.

She was a guest on the 87th episode of the great podcast Ruby Rogues, where she talked about the book and the rules that this post is about. She also gave a talk about this at Baruco 2013. I would like you to listen to the podcast and then watch the talk. They will help you to understand this topic in greater detail than only reading this post will.

The rules

In the Baruco talk Sandi says: “I’m going to give you five rules about how to write object-oriented code. Following these rules will improve your code.

The rules are important so you should always follow them and they’re completely arbitrary so it’s perfectly ok to break them.”

This sets the tone for this topic in that they’re not oppressive rules that you should fear and loathe. The rules are there to help you and it’s fine to break them.

The rules:

1. No more than 100 lines per class
2. At most 5 lines per method
3. 4 (or, as she now prefers, 3) parameters to a method (hash keys included)
4. A controller action may only pass one instance variable per view
5. A controller action may only know two other class names. (One business class and one presenter class)

The why of the rules

1. It forces you to focus the class and make sure that it has a single responsibility
2. This forces you to have well contained private methods and they will help you to have a living documentation of your code.

   def do_thingy
     if foo
       fooify_thingy
     else
       do_other_things
     end
   end
   

   As you can see from the example you are automatically at five lines if you have an if/else statement.

3. “If you have to pass four parameters there’s definitely an object in there.”
4. This is also along the theme of decoupling your application and making sure that you don’t glue everything together in a big mess.
5. A view should be simple and it should be trivial to understand it.

When should I break the rules?

It’s ok to break a rule as long as you can talk another person into believing that is a good idea. The best thing would be if the person who agrees that you can break the rule is someone you trust and that it’s someone with more experience than you.

The consequences of following the rules

An application built by someone that follows all these rules will have a bias towards small objects that are “plain old Ruby objects”. This means that the objects are not coupled to the framework that you are using. Each object only knows as little as possible about other things, which entails that you will have objects with very few dependencies.

The rules are a means to reduce the cost of software. They force you to think hard about your code and make you decide if it’s better to break the class or method in two to make it more focused.

Sandi asserts that you minimize the cost to develop software (time, money, and pain) by making small objects. The only way to make small objects is to define what small really means and then follow that rule.

She also asserts that achieving the goal of producing better software at a lower cost is far more important than following the rules.

The main reason why you should make many small objects make it easy to change the application. If your application contains of a few very large objects, then it will likely be hard to change and adapt to new circumstances and demands.

The downside with many small objects is that they are harder to understand. That is because most of the logic will reside in the messages that get sent between objects. Those messages will materialize when you load the application into memory and it starts its dance, which means that in order to understand it you need to make a mental model of the running program.

One of the upsides on the other hand is that it’s the messages between objects that gives you changeability since the message have to pass the barrier between the objects.

Having many small objects can also help you to feel more safe when you need to change them. You don’t need to understand the whole application and worry about breaking it by changing a seemingly unrelated thing.

What does this mean for me?

I will, for the next few months do my utmost to follow these rules in my current projects for The Gl0d Group. Why? Because I really believe that the rules make a difference and they work in practice. Thoughbot really liked them after trying them out as an experiment on a new project.

You can listen to their thoughts on the experience in the first episode of The Bike Shed podcast.

Ending notes

“If you are an experienced programmer. Make your own rules.” – Sandi Metz

What rules do you follow when you code and what do you think about these?