public
Last active

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/

  • Download Gist
rules.md
Markdown
  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.

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

transcript.md
Markdown

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/

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.

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.

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.

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

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

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.

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

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.