5 ms·

It seems plausible that people would write shorter, clearer functions that have no possibility of being incorrect if they had no tests to gain the confidence of

by dozzie 9y ago

It seems plausible that people would write shorter, clearer functions that have no possibility of being incorrect if they had no tests to gain the confidence of them being correct. Also, designing for testability only gives you testability. If you ditch this requirement, suddenly you're free to design directly for ease of use, not for some proxy like testability.

dpark 9y ago
> It seems plausible that people would write shorter, clearer functions that have no possibility of being incorrect This seems exceedingly implausible. If people were capable of writing perfectly correct functions consistently, they’d do so. Also, in my experience the people who write tests are generally the ones who write good small functions. The people writing massive dense functions are rarely writing good (or often any) tests. (This obviously diverges from the study’s results, though, so grain of salt.)
- 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.)
dllthomas 9y ago
Sure, either way sounds plausible - the point is that this study doesn't tell us how much of an effect runs each way.
ehvatum 9y ago
You are absolutely correct. GLSL shaders were excruciatingly difficult to test and debug, before tooling caught up. As a result, I took great care to write small and easily understood functions. It did much to improve my work in Python and C++, where debugging and unit testing were available. It's irritating to devise guidelines for good development, in general, and then have people build a cult around them. People honestly believe that unit testing is the only incentive for writing good code. This is equivalent to ascribing all good things to Dear Leader and all bad things to an out group.
mannykannot 9y ago
There is no guarantee that all complex problems can be solved in an obviously correct way if you use small enough functions. As the number of functions increases, the complexity tends to get pushed into the interactions between them - and you need integration testing to look for bugs in how they interact. If you are writing small functions - and, generally speaking, you should - integration testing becomes more important than unit testing.

by dozzie 9y ago

dpark 9y ago

> It seems plausible that people would write shorter, clearer functions that have no possibility of being incorrect This seems exceedingly implausible. If people were capable of writing perfectly correct functions consistently, they’d do so. Also, in my experience the people who write tests are generally the ones who write good small functions. The people writing massive dense functions are rarely writing good (or often any) tests. (This obviously diverges from the study’s results, though, so grain of salt.)

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.)

dllthomas 9y ago

Sure, either way sounds plausible - the point is that this study doesn't tell us how much of an effect runs each way.

ehvatum 9y ago

You are absolutely correct. GLSL shaders were excruciatingly difficult to test and debug, before tooling caught up. As a result, I took great care to write small and easily understood functions. It did much to improve my work in Python and C++, where debugging and unit testing were available. It's irritating to devise guidelines for good development, in general, and then have people build a cult around them. People honestly believe that unit testing is the only incentive for writing good code. This is equivalent to ascribing all good things to Dear Leader and all bad things to an out group.

mannykannot 9y ago

There is no guarantee that all complex problems can be solved in an obviously correct way if you use small enough functions. As the number of functions increases, the complexity tends to get pushed into the interactions between them - and you need integration testing to look for bugs in how they interact. If you are writing small functions - and, generally speaking, you should - integration testing becomes more important than unit testing.