3 ms·
I've mentioned those findings here before. It's great to have them listed. It's fascinating that, even with all their limitations and age, they fall so complete
by gruseom 15y ago
I've mentioned those findings here before. It's great to have them listed. It's fascinating that, even with all their limitations and age, they fall so completely on one side of the question - the opposite side to what a lot of sophisticated programmers believe.
The last time we debated this on HN, there was a disagreement about how much complexity the interactions between functions add to a program. To me, complex call graphs are even worse than complex code inside a function. I was surprised to learn that an opposing view even existed.
- berntb 15y ago>>complex call graphs are even worse than complex code inside a function Hear hear. I have a problem specific to that, here. Some programmers follow the "no documentation should be needed, the code is obvious" dogma in a non-typed scripting language -- and you have to look many levels up in the call graph before you even find out about the damn function parameter's types... :-(
- dman 15y agoIdeally you have tests which let you know how every function can be (ab)used.
- berntb 15y agoIf I wrote 2-20 line functions, then I wouldn't document/test every one, either.
- ZeroGravitas 15y agoI think the idea is that the short functions call other (short) functions at a lower conceptual level to create a large amount of functionality. By testing that function, you're testing how they work together. This is different from short functions being short because they don't do much.