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/
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
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.)
How do we refactor code that needs 4 parameters?
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