A 5-line constraint seems ridiculous to me, even in Ruby, and I imagine that just about every codebase ever breaks it. Do you have an example project following such a style?
If your code does a 30 line operation exactly once, it can be inlined. If you want to move it into a function to validate error handling, that is great and now your unit tests help validate code paths.
The fact that is is 30 or 100 lines is immaterial. Making "micro functions" to keep each small just makes it harder to follow the stack. Readability is key and micro functions hurt readability.
In fact the Rule of Three all but says that it’s okay to repeat yourself once, twice is not good, and three is right out. That’s substantially more repetition than DRY prescribes.
Instead, and I admit this sounds a little vague, the code should say what it does. The bigger the thing it’s trying to do, the harder it is to state that clearly, or to verify, so you break it down into separate concepts and string them together. And then you notice how awkward it is to state the same thing many times so you are highly motivated to reuse those statements, refine them, and make them as accurate as possible.
Inlining frequently fails this test because you lose the boundaries of the “thing” that is happening, and people start slipping non sequiturs in, start rambling, which makes it very hard to follow their reasoning.
If you can’t follow their reasoning, you can’t defend it. You won’t defend it. And pretty soon it doesn’t say what it used to and that’s where you get regressions. So if you care about that, you want to write your code so that they understand, in which case breaking your intentions becomes pretty indefensible.
It is idiotic to treat, say, the implementation of some kind of complex 3D rendering algorithm in exactly the same way than you would treat an UI view for a login form.
Guidelines should come with a rationale so that in the very least following them when it contravenes their intent can be justifiably avoided.
If I can't understand and appreciate the rationality behind a guideline and I'm not required by coding standards or tooling to follow it, I'm not going to.
Here's a guideline; don't surrender your common sense and let someone's generalized ideology dictate the design of your program.
While I see advantages to minimizing the length of functions, I can't imagine a well written program following this five line rule.
My concerns are that it increases the length of the source code which damages readability, that it scatters functionality and obscures control flow, and that it unnecessarily requires the formation of many interfaces.
The rule is far too general in it's application "all functions" and at the same time too specific "5" to be useful.
If you said instead "in general, try to make your functions do one thing well and divide and conquer the problems until each function is not very hard for you or someone else to understand",
Then OK.
Admittedly Erlang's powerful pattern matching makes it easier, but it definitely can be applied to multiple languages. The biggest problems I've found trying to apply it are the lack of pattern matching in most languages, and the problem of naming.
1: http://www.gar1t.com/blog/more-embarrassingly-obvious-proble...
2: http://www.gar1t.com/blog/solving-embarrassingly-obvious-pro...