Hi! I hope this isn't offtopic.
The question is where 10 lines per method came from? Why 10 and not 15 or 5 or whatever? Is there some kind of study? Or why 100 lines per class? Or why abc size 15? I don't want to say that I disagree (kind of stupid if I can change it), but it's interesting to know where those default numbers came from. Was it like "100 is cool number let's use it" or "here is a study which shows that 100 is optimal size of a class" ?
I don't think any of those numbers are formally based on science. In fact, it's not hard to find studies that point in the opposite direction saying that large classes are better, for example. It's more a question of finding reasonable default limits so people can attain their metrics goals.
The one I'm responsible for, together with @jfelchner, is the ABC size. I think we just wanted a value that was in harmony with Metrics/MethodLength so the new cop would output roughly the same number of offenses.
Just yesterday, there was a tweet from @martinfowler that happened to mention the number 10 as a method length that he usually stays under.
For me, the important thing is to set limits. It forces you to look at your code and think about it when a certain limit is exceeded. RuboCop's configurable nature lets us set default values without losing much sleep over their exact values. Users can always change them locally.
For me, the important thing is to set limits. It forces you to look at your code and think about it when a certain limit is exceeded.
This is an important point. I often see questions like:
How do I satisfy RuboCop?
Which is okay in the cases where it is used as a style checker, but can be dangerous in others. One thing people often overlook is that low level offenses can reveal higher level smells. This requires the user to figure things out on their own. "Just satisfying RuboCop" in those cases frequently leads to worsening the code.
@Drenmi @jonas054 I think this can be closed out yes?
Just an FYI, there was a rule of thumb in the early days of TDD and agile, called the rule of 10: 10 methods per class, 10 lines of code per method, etc.
It came out of a desire to make code more maintainable, and more testable at a time when the monolithic class/function was usually what you were going to find when you inherited some codebase. It was used as a guideline for when you should refactor, and start splitting code up.
But why 10? Simply because it's large enough to do useful work, and small enough that it's easy to read and test.
I actually found this thread, because I was looking for a reference to the Rule of 10, so I can't point you at the reference yet :)
Not exactly what I was looking for, but here is a ref to the 10 lines idea:
https://sourcemaking.com/refactoring/smells/bloaters
Most helpful comment
I don't think any of those numbers are formally based on science. In fact, it's not hard to find studies that point in the opposite direction saying that large classes are better, for example. It's more a question of finding reasonable default limits so people can attain their metrics goals.
The one I'm responsible for, together with @jfelchner, is the ABC size. I think we just wanted a value that was in harmony with
Metrics/MethodLengthso the new cop would output roughly the same number of offenses.Just yesterday, there was a tweet from @martinfowler that happened to mention the number 10 as a method length that he usually stays under.
For me, the important thing is to set limits. It forces you to look at your code and think about it when a certain limit is exceeded. RuboCop's configurable nature lets us set default values without losing much sleep over their exact values. Users can always change them locally.