Date: Jan 9, 2013 3:15 PM
Subject: how to implement the "many tiny functions" paradigm?
One of the most often cited coding "best practices" is to avoid
structuring the code as one "large" function (or a few large
functions), and instead to break it up into many tiny functions.
One rationale for this strategy is that tiny functions are much
easier to test and debug.
The question is how to implement this "many tiny functions" strategy
To be more specific, suppose that I start with some "large" function
foo, implemented in a ~100-line file foo.m, and I break it down
into about ~20 tiny functions, including a new (and much smaller)
entry-point function foo that calls the remaining tiny functions,
either directly or indirectly.
The problem is that, if the new foo.m file now looks like this:
function f = foo(a, b, c)
% End of function foo
function b = bar(d, e)
% End of function bar
function z = zzz(x, y)
% End of function zzz
...then the "helper" functions bar, ..., zzz are not accessible from
outside foo.m, so there's no easy way to test or debug them
*directly*. (One can do so only indirectly through calls to the
entry-point function foo, and this can be quite cumbersome and
(Note that it would be entirely consistent with the philosophy
described above to have, among the "tiny functions" in foo.m, some
--say, test_bar, ..., test_zzz, etc.--, whose sole purpose was to
test some other "tiny function". Even in this case, however, one
would need a way to call these testing functions from outside of
So file structure shown above may not be very useful for testing
and debugging. On the other hand, it would be too much clutter
(both of directories and of the global namespace) to put all these
tiny functions each in its own *.m file (bar.m, ..., zzz.m,
test_bar.m, ..., test_zzz.m).
So my question is: is there a convenient way to structure this code
that would *both* preserve the overall decomposition into many tiny
functions *and* enable these functions to be tested?
Suggestions would be appreciated.
Thanks in advance!
PS. I am aware of the existence of MATLAB xUnit Test Framework,
etc., but my aims here is more general and fundamental, and in any
case decidedly different, from those of unit testing, and therefore
if possible I'd much prefer to avoid bringing into the picture the
whole unit testing apparatus and mind-set. I'm sure that the
question of the suitability of a unit-testing framework for what
I want to do could provide fodder for lengthy discussions, but this
is a somewhat philosophical point that I'd prefer to avoid altogether.
I hope that responders will be willing to take it on faith my
assertion that MATLAB xUnit Test Framework et al. are not what I'm
after at the moment.