2 ms·

In my experience the people who are the strongest advocates of unit testing write small functions. I left off "good" because I don't agree that "small functions

by sidlls 9y ago

In my experience the people who are the strongest advocates of unit testing write small functions. I left off "good" because I don't agree that "small functions" are "good" necessarily. Often the functions are in fact too small. They properly belong in a larger function as part of that function's implementation, but are "factored out" solely for the purpose of unit testing that piece of the algorithm inside the function. Usually these small functions are also only called once. In that case especially it leads to messy, bloated code that is in fact harder to reason about, harder to maintain and less efficient besides.

arthur_pryor 9y ago
> Usually these small functions are also only called once. In that case especially it leads to messy, bloated code that is in fact harder to reason about, harder to maintain and less efficient besides. the flipside is that if this approach is done well, you end up with things broken down along the natural abstraction lines you'd use, and if you trust that your small functions do the right thing (are tested themselves) and are called correctly (their callers are tested well), it tends to make it much easier to reason about the code, IMHO. but yeah, also, sometimes larger functions and more integration-y tests are the way to go. or the above fine breakdown + unit tests + integration tests. depends on the situation, i think.
- btilly 9y ago
  The tendency is to lock in the first abstraction line that you thought of..which rarely ages well with future experience. My rule of thumb is that something needs to be a function if it is called 3x, doesn't if it is only called from one place, and if it happens 2x it is a judgement call whether to leave cross-referencing comments between the spots or to factor it out into a function. (If it is unlikely that I will need a third and the common code is difficult to extract, I will leave comments.)

by sidlls 9y ago

arthur_pryor 9y ago

> Usually these small functions are also only called once. In that case especially it leads to messy, bloated code that is in fact harder to reason about, harder to maintain and less efficient besides. the flipside is that if this approach is done well, you end up with things broken down along the natural abstraction lines you'd use, and if you trust that your small functions do the right thing (are tested themselves) and are called correctly (their callers are tested well), it tends to make it much easier to reason about the code, IMHO. but yeah, also, sometimes larger functions and more integration-y tests are the way to go. or the above fine breakdown + unit tests + integration tests. depends on the situation, i think.

btilly 9y ago
The tendency is to lock in the first abstraction line that you thought of..which rarely ages well with future experience. My rule of thumb is that something needs to be a function if it is called 3x, doesn't if it is only called from one place, and if it happens 2x it is a judgement call whether to leave cross-referencing comments between the spots or to factor it out into a function. (If it is unlikely that I will need a third and the common code is difficult to extract, I will leave comments.)