3 ms·

> Maybe just try it before calling it a nightmare. I spent the first ~5 years of my career writing code in this fashion. I actually agreed with most of the tal

by lojack 10y ago

> Maybe just try it before calling it a nightmare. I spent the first ~5 years of my career writing code in this fashion. I actually agreed with most of the talk, but this section was a big sticking point with me. Inlining functionality to large procedures has the disadvantage that you need to understand the entire procedure to know what the function does. It also has the disadvantage that you need to test the permutation of every branch within that function in order to fully test the function. That's an order of magnitude more work. Don't even get me started on his stance on TDD (and how correlating it to the failure of OOP makes no sense at all). And, yes, I understand that there can be pros. I've made my stance on the cons very clear, and I strongly feel as though they outweigh the pros. Does it make the moving parts more obvious? Probably sometimes. If you can't come up with good names, and your functions are small enough to begin with, probably. Better naming -- which the presenter addresses -- IMO does a much better job solving this though. His solution is to stop trying to name things, mine is to spend more time coming up with better names.

jstimpfle 10y ago
Thanks for clearing up. He did address the "understanding the entire procedure to know what the function does" part by light use of code comments. Personally I'm not much invested in testing (most of my programming is recreational) but I fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things. The two small ones have obviously more possible code paths since the smaller, driven function is not hidden in the driver function anymore, so can be called in ways that don't actually matter to the purpose of the program. (That's the authors point - he calls it "surface area").
- lojack 10y ago
  > fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things It's understandable how you wouldn't see this without testing experience. Wrote a quick gist to try to explain it as best as I could. https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37d9b https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37... That's a trivial example using pseudocode. But, basically, you'll see that in the longer function example you need 10 test cases to cover all grounds, while in the method thats split apart you need 8. Realistically, I could have further split parseArguments up to simplify those test cases. It seems like a small change, but if you were to add an additional branch to the first method (an if statement) then you'd double the number of tests required. For the longer method thats 10 additional test cases, for the shorter method thats 2.
  - jstimpfle 10y ago
    Realize that both implementations offer the same functionality. You could even say the implementations are basically identical, except for the fact that one gives more "calling surface". So it is is only the "ideal" of 100% branch coverage that misleads you into think you would need more tests. The two branches of the big function don't interact in any way (they could also be paralleized), so 100% branch coverage has no benefit here. In fact you need less tests with the big function if you don't know the context in which the functionality is used, since the surface area is smaller. Another way to look at it is that 100% branch coverage only means all the branches in one isolated function are tested. However, the multiple-functions version calls other functions and the possible branches there are ignored. In other words the interaction with called functions is not tested.

by lojack 10y ago

jstimpfle 10y ago

Thanks for clearing up. He did address the "understanding the entire procedure to know what the function does" part by light use of code comments. Personally I'm not much invested in testing (most of my programming is recreational) but I fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things. The two small ones have obviously more possible code paths since the smaller, driven function is not hidden in the driver function anymore, so can be called in ways that don't actually matter to the purpose of the program. (That's the authors point - he calls it "surface area").

lojack 10y ago
> fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things It's understandable how you wouldn't see this without testing experience. Wrote a quick gist to try to explain it as best as I could. https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37d9b https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37... That's a trivial example using pseudocode. But, basically, you'll see that in the longer function example you need 10 test cases to cover all grounds, while in the method thats split apart you need 8. Realistically, I could have further split parseArguments up to simplify those test cases. It seems like a small change, but if you were to add an additional branch to the first method (an if statement) then you'd double the number of tests required. For the longer method thats 10 additional test cases, for the shorter method thats 2.
- jstimpfle 10y ago
  Realize that both implementations offer the same functionality. You could even say the implementations are basically identical, except for the fact that one gives more "calling surface". So it is is only the "ideal" of 100% branch coverage that misleads you into think you would need more tests. The two branches of the big function don't interact in any way (they could also be paralleized), so 100% branch coverage has no benefit here. In fact you need less tests with the big function if you don't know the context in which the functionality is used, since the surface area is smaller. Another way to look at it is that 100% branch coverage only means all the branches in one isolated function are tested. However, the multiple-functions version calls other functions and the possible branches there are ignored. In other words the interaction with called functions is not tested.