functions vs. script
58 views (last 30 days)
Hello, my question is, what advantages do i have from using functions instead of scripts?
I am writing code with matlab for about one year now, my greatest project was about 1200 lines. I am fine with structuring my code with scripts & subscripts but lately i get in touch with the matlab GUI where i have to face functions. they appear to me as horribly inconvenient relatively to scrips. Can you give my reasons why i should ever use functions instead of scripts?
the pro arguments I have collected so far:
1) the private/public variables aspet. In fact I dont see where the difference is between a variabele that cannot be changed by other scripts/ functions and a variable that is not changed by other scripts by design (although it could if i wanted it to.) So this is no advantage for me.
1)communication between functions is labourus since i have to set the public property multiple times(!) per variable or use handles etc which i recognize as inconvenient but still best option.
2) VERY IMPORTANT: when the program aborts with an error, the workspace of a fuction is lost and i cant use it for debugging. i have to use breakpoints and wait (considerable time... data processing takes time sometimes) until the program gets to the same point again. this is actually what i spend most time on when developing.
so for me its 2:0 for using scripts. any ideas why i should use functions or where they are more practical than scripts?
thank you :)
[edid: sorry, the answeres semm not to show up chronologically, so maybe some comments by me wont fit into the thread at their current position anymore]
Walter Roberson on 12 Mar 2012
While you are doing development, instead of using breakpoints (or as well as using breakpoints), consider using
dbstop if error
dbstop if warning
Then if you get an unexpected crash, you will have access to the context no matter where it is.
More Answers (6)
Daniel Shub on 12 Mar 2012
While I wouldn't term it private/public, the unique workspaces that you hint at in pro 1 is the real selling point to me. With a 1200 line project you might be able to keep the entire scope in your head, but as your programs grow, it will become very difficult to remember all your variable names and make sure you do not change something accidentally. The ability of scripts to freely interact with other scripts makes debugging a nightmare.
As for your cons. Once you get the hang of it, communication between functions is not that hard. Many functions only have a few inputs, other taken parameter value pairs, making it pretty painless. The ability to independently test a function makes debugging so much easier.
G A on 12 Mar 2012
Jan on 12 Mar 2012
Using TRY-CATCH with a meaningful error handling is more useful than running all code in a global context by using scripts. Imagine your code crashs and you want to find the line, which is responsible for the current value of "i". In a bunch of scripts, this can be very hard. If the code is divided into small functions, it is very clear where the definition of a variable must be searched.
Another important aspect is the code-reusability. If you have programmed and tested a function, you can re-use it in another context also. For a script the interaction with the context can lead to inconsistencies, such that a well tested code can fail to work. A typical example is the redefinition of max as a variable:
max = rand(1, 10);
Inside a bunch of scripts, such problems are harder to identify.
Nevertheless, with using enough evalin and assignin calls, you can destroy the stability advantage of the function approach effectively. These commands allow to get the drawbacks of scripts and of functions at the same time.
Joao Henriques on 12 Mar 2012
As you've seen, it's very tempting to use functions as if they were scripts. Many people just use "global" to share variables between functions, and this is as messy as using scripts, so there's no advantage. To get all the advantages of functions, forget "global":
function f(param1, param2)
global a b c
And do this:
function [a, b, c] = f(param1, param2, a, b, c)
You may think this is slow when a/b/c are large, but it's not. Matlab won't do unnecessary copies of variables unless you modify them, so don't be afraid to pass large matrices around.
Some functions will have lots of parameters but when calling them I just copy&paste the definition. It's clear what data each function modifies, and you can redirect input/output at any time. This makes debug much easier.
You can also store parameters in a struct to pass them around. You can extract the variables to make them local (as I'm showing here) or modify the struct directly. Again, don't worry because matlab is smart when it comes to copying memory.
function s = f(param1, param2, s)
a = s.a;
s.a = a;
About the debugging, Walter Roberson is right. With "dbstop if error" active, it automatically creates a breakpoint when there's an error, so you can see what's happening and debug. I recommend you put them in your "startup.m" file so they run automatically when you start matlab.
Stephen on 12 Mar 2012
I find it easier to write separate functions and then just call them as needed with some big script or function instead of copy and pasting lines of code and having to check that the variable names agree. each little function is like a black box that can be inspected on its own that way.