Contenuto principale
Risultati per
Summary:
Dynamically accessing variable names can negatively impact the readability of your code and can cause it to run slower by preventing MATLAB from optimizing it as well as it could if you used alternate techniques. The most common alternative is to use simple and efficient indexing.
Explanation:
Sometimes beginners (and some self-taught professors) think it would be a good idea to dynamically create or access variable names, the variables are often named something like these:
- matrix1, matrix2, matrix3, matrix4, ...
- test_20kmh, test_50kmh, test_80kmh, ...
- nameA, nameB, nameC, nameD,...
Good reasons why dynamic variable names should be avoided:
- Slow
- Buggy
- Security Risk
- Difficult to Work With
- Obfuscated Code Intent
- Confuses Data with Code
- Code Helper Tools do not Work
- Magically Making Variables Appear in a Workspace is Risky
There are much better alternatives to accessing dynamic variable names:
- Indexing into Cell Array or ND-Array
- Non-scalar Structures (with Indexing)
- Dynamic Field-Names in a Structure
- load into a Structure, not into the Workspace
- save the Fields of a Scalar Structure
- Use a table or timetable Array
- Use more Efficient Ways to Pass Variables Between Workspaces
Note that avoiding eval (and assignin, etc.) is not some esoteric MATLAB restriction, it also applies to many other programming languages as well:
MATLAB Documentation:
If you are not interested in reading the answers below then at least read MATLAB's own documentation on this topic Alternatives to the eval Function, which states "A frequent use of the eval function is to create sets of variables such as A1, A2, ..., An, but this approach does not use the array processing power of MATLAB and is not recommended. The preferred method is to store related data in a single array." Data in a single array can be accessed very efficiently using indexing.
Note that all of these problems and disadvantages also apply to functions load (without an output variable), assignin, evalin, and evalc, and the MATLAB documentation explicitly recommends to "Avoid functions such as eval, evalc, evalin, and feval(fname)".
The official MATLAB blogs explain why eval should be avoided, the better alternatives to eval, and clearly recommend against magically creating variables. Using eval comes out at position number one on this list of Top 10 MATLAB Code Practices That Make Me Cry. Experienced MATLAB users recommend avoiding using eval for trivial code, and have written extensively on this topic.
Some of Matlab's toolbox functions are affected by magic strings or magic numbers, which are strings or numbers with a deeper meaning besides the normal value. Both are considered as bad programming patters, because they provoke confusions, when the magic keys appear with the normal meaning by accident. See http://en.wikipedia.org/wiki/Anti-pattern
Example 1:
clear('myVariable')
clear('variables')
While the 1st clears the variable myVariable, the later clears all variables. Here 'variables' has a meta-meaning. The problem appears, when 'variables' is an existing variable:
a = 1;
variables = 2;
clear('variables')
disp(a) % >> 1
Only variables is cleared, which cannot be understood directly when its definition is 1000 lines before.
Example 2:
uicontrol('String', 'default')
This creates a button with the empty string '' instead of the expected 'default', because this is the magic string to invoke the default value get(0, 'DefaultUIControlString'). The same concerns properties of other graphic objects also, e.g. the 'name' property of figure or the string of uimenu. There is a workaround which allows the user to display 'default': Simply use '\default'. Unfortunately this is doubled magic, because in consequence it is impossible to display the string '\default'. Obviously a bad idea.
Example 3:
Graphic handles are doubles (although gobject of the new R2013a seems, like this is subject to changes? [EDITED: Yes, it changed with HG2 in R2014a]). But then a handle can be confused with data:
a = axes; % e.g. 0.0048828125
plot(a, 2, '+')
But you cannot draw the point [0.0048828125, 2] by this way, because the 1st input is considered as handle of the parent. Here all possible values of handles are magic. Collisions are very unlikely, but there is no way to avoid them reliably - as long as handles have the type double.
Question:
Which functions are concerned by magic values? What are the pitfalls and workarounds?