Skip to content

Instantly share code, notes, and snippets.

@henrik
Last active May 23, 2022 12:31
Show Gist options
  • Save henrik/4509394 to your computer and use it in GitHub Desktop.
Save henrik/4509394 to your computer and use it in GitHub Desktop.
Sandi Metz' four rules from Ruby Rogues episode 87. Listen or read the transcript: http://rubyrogues.com/087-rr-book-clubpractical-object-oriented-design-in-ruby-with-sandi-metz/
  1. Your class can be no longer than 100 lines of code.
  2. Your methods can be no longer than five lines of code.
  3. You can pass no more than four parameters and you can’t just make it one big hash.
  4. When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.

You can break these rules if you can talk your pair into agreeing with you.

SANDI: I’ve been wanting to give — okay, so people wanted rules for me like when I go out and see strangers when I look at their code. So, I finally gave them some rules and the rules are, and this is painting a big target on me to give you these rules. But I want to say them to you and see what you guys think about them.

SANDI: Okay. So, I ended up giving, “This is the bottom line. Your class can be no longer than 100 lines of code. Your methods can be no longer than five lines of code.” I wanted four but I felt like I had to give them five. “You can pass no more than four parameters and you can’t just make it one big hash. Your controller, in a Rails app, when a call comes into your controller, you can only instantiate one object to do whatever it is that needs to be done.”

SANDI: “And that your view can only know about one instance variable.” So those are the rules I gave them. I told them they could break them, right? They could break them.

CHUCK: So, one thing that really strikes me with these rules is that for the most part, if you really try, you should be able to follow them. And if you can’t follow them — see, this is the thing with programming rules that I think people don’t understand is that when you say, “I’m giving you this rule,” they think, “Oh well, I’m sure I can find an instance that breaks this rule.” The whole point is yeah, but when you break the rule, you should be able to explain exactly why you need to break the rule. In that way, then you can justify what you’re doing. But otherwise, you’re not forced to think about what you’re coding and that’s really what the issue is.

SANDI: I told them they could break the rules if they could talk their pair into agreeing with them.


Source: http://rubyrogues.com/087-rr-book-clubpractical-object-oriented-design-in-ruby-with-sandi-metz/

@pirj
Copy link

pirj commented Feb 6, 2013

Add Law of Demeter to the mix, control with Pelusa (which insists on 50 LoC per class, max 3 ivars, detects deep nesting etc) and you have a chance to have good code. That is unfortunately not so easy to write if you were coding at will previously.

@bf4
Copy link

bf4 commented Mar 22, 2013

Another version of the rules generated on the ruby rogues list http://gist.io/4567190

@felixyz
Copy link

felixyz commented Mar 8, 2016

Hey @philipschwarz I went ahead and read your presentation and really liked it. Just wanted to let you know!
(I was reading The Practical Guide to Structured Systems Design recently so that connection was very interesting.)

@AnwarShah
Copy link

How do we refactor code that needs 4 parameters?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment