this function masks the builtin "clear" and carefully checks to make sure that "all" (or the default zero-argument case, which MathWorks foolishly made equivalent to "all") is not in the argument list. It accepts any mixture of string and cell arrays of string arguments.
Further, this function checks whether it was called from the console. If not , i.e. was called from within a function, it reverts to the builtin "clear" function so that function environments can be cleared as would normally happen.
With thanks to Cris Luengo and Andrew Janke over at StackOverflow.
Carl Witthoft (2019). Replacement for CLEAR to avoid destructive behavior (https://www.mathworks.com/matlabcentral/fileexchange/71405-replacement-for-clear-to-avoid-destructive-behavior), MATLAB Central File Exchange. Retrieved .
" I don't recommend anyone use CLEAR, ever, period, but one accidental use..:"
I am still not convinced that this is the solution. I understand that we humans are fickle creatures, but apart from forcing those users into writing inefficient code (see my earlier comment), using a wrapper like this just creates a latent problem that will come back and bite them in the future: one day when some code is distributed without it or the search path changes or whatever happens (such things will inevitably occur) and this function is **silently** ignored in favor of the inbuilt one, then the poor user will be inexplicably faced with exactly the same issue, and they will still have no idea why code that worked yesterday/with Sally/on that other computer is now buggy. They will be right back at square one, without having learned anything about when to use CLEAR (i.e. almost never) and without having actually improved their code. Not only that, but its behavior could even change if they enter debug mode or anything else that has an effect on function scoping. Ouch!
The basic issue is that this submission does not actually "fix" the problem, it merely hides it under some circumstances, and the user will have no warning of when those circumstances have changed.
Anyway, finding "one accidental use" of CLEAR is easy: the MATLAB IDE and all text editors that I have used can search for text in multiple files. Is it so hard to track down "one accidental use" of CLEAR ?
While certainly interesting as an experiment, I would put this in the same category as GOTO and the other runtime hacks that I have seen submitted to FEX.
"I can't even count the number of people within my company who were taught to start every script with "clear; clf"..."
Someone actually *taught* them to do that?! Oh, the humanity!
Stephen, I fully agree with you. However, given the malevolent behavior of CLEAR (this is MathWorks' fault), I provide this as a safety tool. I don't recommend anyone use CLEAR, ever, period, but one accidental use, given that the default action when there are no arguments is to "clear all," this function keeps that from happening. It's easy to write "stop using CLEAR inappropriately" but much harder to ensure humans do so. I can't even count the number of people within my company who were taught to start every script with "clear; clf" and have very little understanding of software in the first place.
The simpler solution is to not call CLEAR.
MATLAB's inbuilt memory handling is quite good at managing memory allocation and tidying up unused variables. Only rarely is it required to CLEAR variables explicitly or to CLEAR compiled functions from memory (in which case CLEAR can be called with those specific names). Most of the time, well-written code (i.e. functions, passing arguments, etc) will be much more efficient without CLEAR and allows MATLAB to manage the memory usage automatically, just as it was designed to do.
This code is the exact opposite of that. It calls EVALIN to magically mess around in other workspaces, and relies on slow introspective programming via DBSTACK. While interesting as a thought experiment, this approach to writing code "fixes" pointless CLEAR usage by writing slow and complex code that totally interferes in MATLAB's JIT processes and memory management. The MATLAB documentation explains that for efficient code EVALIN and DBSTACK should be avoided:
Inefficient code should be avoided, especially as the alternative is much simpler: stop using CLEAR inappropriately.
cleaned up comments