4 ms·

Method length should be 1 to 3 lines. Longer and you are incurring technical debt. The function name should be descriptive and it's description shouldn't be, 'a

by nahname 14y ago

Method length should be 1 to 3 lines. Longer and you are incurring technical debt. The function name should be descriptive and it's description shouldn't be, 'adds_one_to_a_number_unless_override_is_on_then_it_subtracts_four_except_when_global_is_set_then_it_jumps_into_a_switch'

berntb 14y ago
>>Method length should be 1 to 3 lines. I've read that claim. The only time I really had to work with code like that was horrible. It was like a book where the sentences were in random order, with the next sentence number appended, so you would have to browse to another page every few words. :-( The context switches didn't make me productive... Sometimes, I had to look 3-4 levels up or down in the hierarchy to find a parameter type (this was in a scripting language). If anyone talked to me, it took a looong time to rebuild the model in my head. Edit: In short, grandparent++.
- taproot 14y ago
  Lasagne is starting to sound a lot like Spaghetti, I guess that's the point.
SoftwareMaven 14y ago
No, no, no, no. Did I mention no? I inherited a Javascript application that was maybe 1500 lines of code. Every function was 3-5 lines. Most were like this: process_foos = function(my_list) { for (i=0; i<my_list.lengh; i++) { process_foo(my_list[i]); } } process_foo = function(foo) { foo.some_method(); } And foo.some_method (in another file) was similar. What it meant was it was impossible to get a view of what was going on in the system. It took months to accomplish an understanding that should have taken weeks. I really think the original authors heard your advice and decided comprehension didn't matter, only function length. Function should accomplish a task. Sometimes (very rarely) a task may be two hundred lines; usually, it is much shorter. Sometimes three lines, but often 15-20.
danneu 14y ago
I used to believe that, but after a while I realized that it's a heuristic derived from code that's already split up into clear responsibilities. Large methods are only a symptom that this component of your system does too much and probably has too many dependencies. Small methods do nothing for you except add indirection if you've not solved the dependency problem, and adding indirection to an entangled system is even worse than having large methods. In other words, somehow an aspect of the end result of clear code became common advice, probably because it's so obvious and replicable. "Write decoupled code with focused responsibilities" on the other hand is nebulous. It's sort of like when dating advice is simplified into "be mean to girls".

by nahname 14y ago

berntb 14y ago

>>Method length should be 1 to 3 lines. I've read that claim. The only time I really had to work with code like that was horrible. It was like a book where the sentences were in random order, with the next sentence number appended, so you would have to browse to another page every few words. :-( The context switches didn't make me productive... Sometimes, I had to look 3-4 levels up or down in the hierarchy to find a parameter type (this was in a scripting language). If anyone talked to me, it took a looong time to rebuild the model in my head. Edit: In short, grandparent++.

taproot 14y ago
Lasagne is starting to sound a lot like Spaghetti, I guess that's the point.

SoftwareMaven 14y ago

No, no, no, no. Did I mention no? I inherited a Javascript application that was maybe 1500 lines of code. Every function was 3-5 lines. Most were like this: process_foos = function(my_list) { for (i=0; i<my_list.lengh; i++) { process_foo(my_list[i]); } } process_foo = function(foo) { foo.some_method(); } And foo.some_method (in another file) was similar. What it meant was it was impossible to get a view of what was going on in the system. It took months to accomplish an understanding that should have taken weeks. I really think the original authors heard your advice and decided comprehension didn't matter, only function length. Function should accomplish a task. Sometimes (very rarely) a task may be two hundred lines; usually, it is much shorter. Sometimes three lines, but often 15-20.

danneu 14y ago

I used to believe that, but after a while I realized that it's a heuristic derived from code that's already split up into clear responsibilities. Large methods are only a symptom that this component of your system does too much and probably has too many dependencies. Small methods do nothing for you except add indirection if you've not solved the dependency problem, and adding indirection to an entangled system is even worse than having large methods. In other words, somehow an aspect of the end result of clear code became common advice, probably because it's so obvious and replicable. "Write decoupled code with focused responsibilities" on the other hand is nebulous. It's sort of like when dating advice is simplified into "be mean to girls".