Skip to content

Instantly share code, notes, and snippets.

@henrik
Last active May 23, 2022 12:31
Star You must be signed in to star a gist
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/

@galtenberg
Copy link

Rule 4 is great, but rule 2 will just blast a use case apart and across many less-than-vital objects.

Don't fear a use case orchestrated in one main place. Can be more understandable that way.

@cwharris
Copy link

cwharris commented Feb 4, 2013

I like all of them, minus the 5 lines per method. Particularly because it will simply encourage developers to cram more into one line. Instead, consider stressing the importance of a single responsibility per method, as it relates to the class which contains it.

Really good rules, none-the-less. A target must be made before convergence can take place.

@jbrains
Copy link

jbrains commented Feb 4, 2013

These are Novice Rules. They're meant to teach you things. Your goal is to learn those things so that you can move away from the rules. Don't bother following Novice Rules that don't encourage you to do something you don't like.

@jonreid
Copy link

jonreid commented Feb 4, 2013

I don't think these are Novice Rules. If anything, it's the Old Hands that need them because "I've got the experience it takes to stay on top of this massive glob of code."

If you think the 5-line method is impractical or pointless, watch http://www.cleancoders.com/codecast/clean-code-episode-3/show

@philipschwarz
Copy link

In Code Complete, Steve McConnell says that if it makes sense to make a certain method 100, 150, or 200 lines long, it is probably right to do so. He also says that when you go past 200 lines you are bound to run into an upper limit of understandability.

In Smalltalk Best Practice Patterns Kent Beck says that good Smalltalk methods, written using the Composed Method pattern (and ancillary patterns), are certainly less than 10 lines long, and sometimes about 3 or 4 lines long.

In Refactoring to Patterns, Joshua Kerievsky says that Java methods written using the Composed Method pattern are rarely more than 10 lines, and usually about 5 lines.

To be fair to Beck, in Implementation Patterns he says "How long should a method be? Some people recommend numerical limits, like less than a page or 5-15 lines. While it may be true that most readable code satisfies such a limit, limits beg the question “why?” Why do chunks of logic work out best when they are about so big?...Compose methods based on facts, not speculation. Get your code working, then decide how it should be structured."

I made the above the subject of the following presentation: Four Patterns at the Heart of Good Programming Style.pdf https://docs.google.com/file/d/0B58HKx0bzlVrOE5WZFh0elZMYUk/edit

@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