MATLAB: Functions vs. script

script function public private

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.

Con arguments:

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]

Best Answer

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.

Related Solutions

MATLAB: Systematic: Do not use global, don’t use eval

EVAL is evil: Experience! Not just my own experience. Many times on CSSM and even here on answers a user asks, "How can I create these hundreds variables A_1, A_2,..." We try to tell him not to do it. Then a few days later he comes back, "I can't figure out how to process my hundreds of variables!" or "Why is my code so slow?" or "I can't find the bug in my code." And guess what? Nobody can help because the code is a mess of strings that is nearly unreadable. When it is not necessary, why use it? Why teach a beginner to program is such a way?

I do agree that there are times when EVAL is the only choice - fine. Just because there are exceptions doesn't mean that it should be the rule to use it. I would rather a user learn to program with efficient variable storage techniques, and program using best practice standards, and only much later discover EVAL.

Globals not good: Experience! In my work I help others with MATLAB. Beginners dive right in to globals because they think using them is easy. They are also easy to do wrong. Too often in my work I have to trace through all a user's M-files that use globals, and the base workspace, to find where the user accidentally made a change that is bugging up a entire complicated project. Each function has its own workspace for a reason(s) - and easy bug tracking is one. I always end up teaching people to program by careful data management rather than relying on globals. Usually they have less problems after that with "Where the @#$#*@ is the bug!"

They are another one I would rather see someone discover much later in their programming career. By that time they should know all the pitfalls and how to manage things carefully anyway.

I liken these things to using GOTO. Sure, one can use it just fine, and some may even prefer it to structured programming. But that doesn't mean it is a good idea - especially for beginners. Just like no Intro To MATLAB book I have seen teaches the user to turn to EVAL and globals (in fact many discourage these things), we as more experienced users ought to teach best practices and use these things only as necessary when coaching novices.

MATLAB: Experts of MATLAB, how did you learn? Any advice for beginner/intermediate users

I reject the label "expert", but here is my two cents worth anyway:

MATLAB Specific:

MATLAB has a great feature that very few programming languages have: readable documentation. Use it! Search it using your favorite internet search engine. Practice browsing it via the contents on the left-hand side (which are all hyperlinks). Understand how it is grouped by topic. Try out the examples. Use the help to locate related functions and advice on how to solve particular problems.
Read the help for every function and operation that you use, no matter how trivial you think that operation is. Half of the questions that we answer on this forum are solved by reading the documentation for the function/operator that the user is already using!
Learn to use the debugging tools. These are indispensable. Read about how they work and what they do, then practice using them! For starting debugging, the most useful command is: dbstop if error
Learn the differences between array and matrix operations, otherwise your calculations will simply produce nonsense and you won't know why. If you are not doing linear algebra you need array operations.
Learn about comma-separated lists, and the easy ways to use them.
Pay attention to all of the code warnings, error messages, underlining, and tips that the MATLAB Editor shows. Do not ignore these messages.
Make vectorized code your first choice when writing code, and leave those ugly low-level loops behind you... Understand why vectorized code is beautiful, and how it can be used to make your code much more efficient and easier to understand.
And of course when loops are required, always preallocate the arrays before the loops.
There are important ways to write fast and efficient code. Use them.
For example, use absolute or relative filepaths instead of slow and hard-to-debug cd.
Learn good MATLAB programing habits right from the start, because life is too short to un-learn bad habits! This means: comment your code, use consistent formatting, write help (with H1 line) in every function, pass variables properly, use input checking, never use eval (or assignin, feval, etc), etc.
Do not force meta-data (e.g. dates, times, indices, test parameters, etc) into variable names or fieldnames: meta-data is data, so store it as data in an array.
Use subs to substitute values into a symbolic expression and evaluate it. Do not use eval to do this, it is not the correct tool for the job!
Write functions, not scripts. Scripts are good for playing around with, but not for real work.
Refer to all graphics objects (figures, axes, lines, etc) using explicit handle references (e.g. using Parent property). This makes plotting and handling graphics robust and predictable. Do not assume that the current figure/axes/etc is going to be the one that your code needs to access.
Pass variables reliably using input/output arguments and do not use globals or assignin. If you need to pass lots of values (e.g. simulation parameters) then put them into a structure and pass that.
MATLAB blogs are an excellent source of inspiration and ideas. Loren Shure's blog is a mine of great ideas, and a veritable pleasure to read too.
Check out other people's code on File Exchange (FEX). Note that the comments are often more useful than the ratings... and you will soon get an idea of whose comments are particularly worth paying attention to.

General Advice:

Imagine that every script and function you write is going to be given to someone else... impress them!
Test everything thoroughly. Check each line as you write it. Does it really do what you think it is doing? Many beginners come here to ask for help because they only think about what they want their code to be doing, but never bother to actually check what their code really is doing. Code cannot read your mind.
Make a set of test-cases and collect all of the instances that fail while the code is being written, plus all the edge-cases and every case category that it needs to work with. You will not regret doing this.
Break problems into parts, solve the parts separately. Make functions for code that needs to be repeated: this allows code to be reused, and bug-fixed in one location. Scripts are great for quickly testing an idea, but functions are much more robust for anything that will be used for more than one day.
Think about what you are doing: actually think. What is the problem being solved? What is really the problem? How can it be solved? With what methods? Read Pólya's excellent book How To Solve It.
Don't get stuck believing that you have found the best solution... there can be a much better solution waiting just around the corner, that may just require a new perspective, a reformulation of the problem, or a slight rearrangement of the data.
Practice! Challenge yourself with tasks you want to solve, or take part in onlne code challenges or tutorials.

Best Answer

Related Solutions

MATLAB: Systematic: Do not use global, don’t use eval

MATLAB: Experts of MATLAB, how did you learn? Any advice for beginner/intermediate users

Related Question