5 ms·

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

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?

pulisse 7y ago
In Ruby, Rails and many projects in the Rails ecosystem aspire to it. The result is (to me) poor code locality and unreadably deep call stacks.
- anon1m0us 7y ago
  I can't imagine ever choosing RoR for a safety critical system.
- deleted 7y ago
  [deleted]
jcelerier 7y ago
What is ridiculous is to have blanket rules & constraints instead of guidelines that can be followed or not depending on common sense and the actual case. 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.
- ajxs 7y ago
  Nearly all of the front-end developers I've suffered the misfortune of working with over the years have been aghast at the notion that their UI code might be responsible for anything less than the fate of all mankind. Ironically, this has done nothing to raise the shockingly low standard of web development.
sethammons 7y ago
My general rule is that a function should help keep things DRY and/or easier to test. Functions should be _reused_. 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.
- hinkley 7y ago
  DRY is overrated, and lesser engineers can make a hash of your entire codebase in the name of DRY (and don’t get me started on DRY tests. Fuck me.) 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.
  - sethammons 7y ago
    Totally agree
macintux 7y ago
Garrett Smith advocates for tiny functions; here are his blog posts about Python[1] and Erlang[2]. 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-problems.html http://www.gar1t.com/blog/more-embarrassingly-obvious-proble... 2: http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html http://www.gar1t.com/blog/solving-embarrassingly-obvious-pro...
- pnako 7y ago
  It's horrible. The next sentence tells why. It's horrible because of something. That something is noise. The noise is because of indirections. No one talks like that.
thender21 7y ago
A static analysis report of published codebases regarding metrics like line length per function would be interesting to see. 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.

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?

pulisse 7y ago

In Ruby, Rails and many projects in the Rails ecosystem aspire to it. The result is (to me) poor code locality and unreadably deep call stacks.

anon1m0us 7y ago
I can't imagine ever choosing RoR for a safety critical system.
deleted 7y ago
[deleted]

jcelerier 7y ago

What is ridiculous is to have blanket rules & constraints instead of guidelines that can be followed or not depending on common sense and the actual case. 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.

ajxs 7y ago
Nearly all of the front-end developers I've suffered the misfortune of working with over the years have been aghast at the notion that their UI code might be responsible for anything less than the fate of all mankind. Ironically, this has done nothing to raise the shockingly low standard of web development.

sethammons 7y ago

My general rule is that a function should help keep things DRY and/or easier to test. Functions should be _reused_. 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.

hinkley 7y ago
DRY is overrated, and lesser engineers can make a hash of your entire codebase in the name of DRY (and don’t get me started on DRY tests. Fuck me.) 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.
- sethammons 7y ago
  Totally agree

macintux 7y ago

Garrett Smith advocates for tiny functions; here are his blog posts about Python[1] and Erlang[2]. 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-problems.html http://www.gar1t.com/blog/more-embarrassingly-obvious-proble... 2: http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html http://www.gar1t.com/blog/solving-embarrassingly-obvious-pro...

pnako 7y ago
It's horrible. The next sentence tells why. It's horrible because of something. That something is noise. The noise is because of indirections. No one talks like that.

thender21 7y ago

A static analysis report of published codebases regarding metrics like line length per function would be interesting to see. 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.