The Problem with clc; clear; close all; ?

A few days ago someone pointed out that using:

clc; clear; close all;

Is considered as a case of code smell and cargo cult programming.

But does that really have to be the case?

clc: cleans up the command window and now one can work without getting confused with the commands for previous runs

clear: erases the variables from previous runs this will reduce chances of error in subsequent runs and the programmer does not have to worry about unnecessary trash variables.

close all: closes all currently open figures. This can be very helpful during subsequent runs of the same script. If the figure from the previous run has not been closed then the subsequent run will plot the data on the already open figure. Which of course is a total waste.

What is the problem with using these commands?

[per isakson]

"clear: erases the variables from previous runs" use clearvars for that rather than clear , which does so much more.

[kunal goswami]

thanks ;

Answer 1

[Rik]

My main point is that people will get into the habit of using this, and will also use it in functions.

Clear is almost never needed in normal use, as you can use functions to keep your workspace clean. Close all should also be avoided, as you should use explicit handles to make your code robust. If there is an unexpected close all in a function, that will be annoying.

The big exception is during debugging. If you're using a script to quickly check something, these are fine. That is why all Image Analyst's demos start with it, and why you probably won't find any of them in his functions (with the possible exception of clc).

[atharva aalok]

Thanks makes much more sense now.

[Walter Roberson]

There are cases where clearing a variable can be warranted, if you are using large enough variables that you are likely to run across memory limits, and the variable is not being used in a tight loop.

Clearing a variable forces the optimizer to recompute whether a future reference to the name should be treated as undefined or as a function call. For example,

gamma = 1:10;
gamma(5)
clear gamma
gamma(5)

After the clear, gamma did not become undefined: it became a reference to a function.

Much of the time, MATLAB can make block-level predictions about whether any given name resolves to a variable or a function, but when you clear a variable it cannot do that anymore, so the code slows down.

Thus, if you have the memory, it is more efficient to leave the clearing to be automatic from returning from a function.

See my timing tests at https://www.mathworks.com/matlabcentral/answers/60240-what-is-the-difference-between-the-effect-of-clear-and-clearvars#answer_757137 -- which, by the way, indicate that clearvars can be much much slower than clear.

Answer 2

[Stephen23]

"What is the problem with using these commands?"

Nothing... when they are used from the command line whilst you are experimenting and developing new code.

However there are many overlapping problems with those commands when they are used in scripts and functions.

Here are just a few:

• Superfluous code is bloated code. Code should include only that which is required for its functionality: does COS() close all open figures? Or does it only calculate the cosine of an angle (just as it should)?
• Robust code is focussed on one functionality, and does not mess around with unrelated tasks. Does SQRT() clear everything from the command window?
• Independence is achieved by using functions and classes (just like all the MATLAB's toolboxes and all well-written code on FEX), not by clearing a shared workspace.
• They are anti-pattern cargo-cult code. Proof: the number of threads on this forum where beginners cause pointless bugs by placing those commands at the start of random functions and scripts they have written (which they then cannot debug by themselves).

Your list of "benefits" of those commands is unlikely to convince many experienced users.

"cleans up the command window and now one can work without getting confused with the commands for previous runs"

I work with gigabytes of data in hundreds of thousands of files. I certainly do NOT print out the "commands for previous runs", nor even much data (with so much data printing it would not be very useful anyway). At most I might print something short at the end of an iteration perhaps, to let me know that an interation is complete. If I need a log file, then I can write a log file to read at my own leisure.

Spamming lots of data to the command window is the problem here, not clearing it.

"clear: erases the variables from previous runs this will reduce chances of error in subsequent runs and the programmer does not have to worry about unnecessary trash variables."

Which is another reason why using functions/classes is much better than scripts: they avoid this by design.

Note that once you put anti-pattern commands at the start of your code like CLEAR or CLOSE (or make eveything require user INPUT) then you are stuck in an untestable, ungeneralizable, unexpandable dead-end.

Why does your code have "unnecessary trash variables" anyway?

"closes all currently open figures. This can be very helpful during subsequent runs of the same script. If the figure from the previous run has not been closed then the subsequent run will plot the data on the already open figure."

Using explicit graphics handles is much more robust, gives you more control, and can avoid this problem entirely.

Answer 3

[David Cazenave]

I learned from my MATLAB professor at Allan Hancock College to use clear all, and this was verified when I first started testing my script 'Series Convergence Calculator.' In the beginning I used clear variables I think, but that doesn't clear the symbolic engine like clear all does, so after I would rerun my script (to keep testing), the left-over remnants in the symbolic engine would corrupt my results for the current run. clear all cleans every thing, including the symbolic engine, and with my script (and testing) it's crucial. I use clear all with all my scripts.