Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.


Math Forum » Discussions » Software » comp.soft-sys.matlab

Topic: how to implement the "many tiny functions" paradigm?
Replies: 7   Last Post: Jan 10, 2013 4:10 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Yuri Geshelin

Posts: 148
Registered: 10/15/07
Re: how to implement the "many tiny functions" paradigm?
Posted: Jan 9, 2013 5:40 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

kj <no.email@please.post> wrote in message <kckj4h$m4s$1@reader1.panix.com>...
>
>
> 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.
>
> 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
> error-prone.)
>
> (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
> foo.m.)
>
> 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.


Two things come into my mind.

First, if you want to adopt the good practice of writing small functions, do it at the initial stage when you create the code. Put your immediate thoughts into lines of the code. That way, you create small functions, one by one, which accomplish the task at hand. If the code already exists, you may break it into a few functions if it comes in handy, but there is no point in setting a goal of slicing a 100-line code into 20 tiny ones. No need to do it on purpose.

Second, why are the newly created functions not accessible from outside the original foo.m? What prevents you from saving them in separate files? You are going to debug each one of them anyway?



Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.