dpb
Posts:
6,677
Registered:
6/7/07
|
|
Re: how to implement the "many tiny functions" paradigm?
Posted:
Jan 9, 2013 4:26 PM
|
|
On 1/9/2013 2:15 PM, kj wrote:
> 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
> in MATLAB.
...
[BUT]
...
> ...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
> error-prone.)
...
> 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.
...
I don't know of any way to have both -- what I've done in the past some
(altho not religiously and I won't claim it's any great revelation) is
to write/test the helpers independently then put them into the larger
container file when they're vetted.
This (somewhat) follows the Forth idea of writing words from bottom up
but Forth doesn't have the same visibility/scoping within a file as does
Matlab unless one builds it w/ dictionaries.
It is, unfortunately, sorta' a remnant of Matlab having "just growed"
from the initial concept and not sure there's any solution w/o a major
restructuring that's probably not likely (any time _real_soon_now_ (tm)
anyway).
--
|
|
