How can I declare lots of global variables in one m-file and make them visible for all my functions in all other m-files?

I was thinking about putting all my global variables in one m-file in order for me to have an overview on my global variables.

I know that you should declare global variables in each and every function, because each function has its own workspace. I know that declaring a variable with the keyword global in each function makes a copy of the same variable and changes made on the copies are like made on the original...

This is fine as long as I have few global variables and few functions, but I have many variables, which I would like to introduce them to many functions... Later I will adopt an object oriented style, but first I need to analyze the program.

If I would like to declare all my global variables in a separate script or m-file, how should this be done? And how do I make these variables visible in the workspace of many other functions in many other m-files?

Thank you for your help and support in advance!

[John D'Errico]

Zillions of global variables are just bad news. Bad, lazy programming style. They will give you buggy code, because you will have one heck of a bad time figuring out where some variable got stepped on. Sorry, but true. Pure hell to debug when you have problems.

[Stephen23]

Lets have a look at what the people who write MATLAB say about globals:

https://blogs.mathworks.com/videos/2010/03/08/top-10-matlab-code-practices-that-make-me-cry/

Or what other people say about using globals:

https://www.mathworks.com/matlabcentral/answers/51946-systematic-do-not-use-global-don-t-use-eval

http://www.mathworks.com/matlabcentral/newsreader/view_thread/287891

https://www.mathworks.com/matlabcentral/answers/319613-how-to-use-global-variable-as-local-variable

https://www.mathworks.com/matlabcentral/answers/281678-automatically-define-global-variables

https://www.mathworks.com/matlabcentral/answers/228557-experts-of-matlab-how-did-you-learn-any-advice-for-beginner-intermediate-users

The last page has this very nice quote: "I disagree that it's fine for beginners to use eval and global. These are of course the easy way out, but you never get better at anything by taking the easy way out and you don't learn how to do things in the best matter."

"Thus I would say it's especially important that beginners specifically don't use eval, globals etc. since they are not seasoned enough to know the dangers of these tools and the fact that there are better things they could learn."

And a comment on the question: "And how do I make these variables visible in the workspace of many other functions in many other m-files?"

You don't. That is a terrible way to write code. A function is a black box: it has clearly defined input and output arguments (which can be checked and debugged easily). What happens inside the black box (i.e. what variables) is irrelevant to the outside world.

Global variable is the opposite of good programming: it makes your variables impossible to keep track of when they change, and very hard to debug. Beginners sometimes want to make all workspaces access the same variables and try to use globals to achieve this: this is a guaranteed way to write buggy spaghetti code.

Learn to pass data in a more efficient and robust way:

https://www.mathworks.com/help/matlab/matlab_prog/share-data-between-workspaces.html

Answer 1

[Jan]

Putting a bunch of variables in one M-file and sharing them as globals is the best way to loose the overview. As soon as they are changed in any subfunction, even if it happens by a typo, the debugging gets horrible.

How do you keep the overview at your home? Do you store each item at a location, where it belongs (forks in the cupboard in the kitchen, screw-driver on the work bench?) or do you collect all item in front of your house on the street, one beside the other?

Start an object oriented programming style now, not later. Store the details locally only and hide it from the outside. Hide the details, such that only the well defined interface of code blocks is visible from the outside. Then you can be sure, that a working part of your code cannot be disturbed from anywhere. And vice versa you can modify the internal details of a function however you want, as long as the interface to the outside remains as defined.

Keep the code simple and clean. Avoid globals and even more a bunch of globals.

[Ahmed Hossam]

Well I wouldn't want to put my forks and screw drivers on the street. Let's say I want to put them all on one table in order to know what is a fork and what is a screw driver.

Let's assume that I'm a carefull typer and that I wouldn't make mistakes when typing the names of the variables. Is it possible to put all global variables in one m-file and make them visible in the workspace of every function? If yes, how is this done in detail? How should the m-file look like, which includes all my global variables? A function, which includes all my global variables didn't work, because after the function was called the local workspace of that function was gone! And how do I tell my other functions: hey, please do my a favour and put these global variables in your workspaces?

I understand this is horrible, but I have a huge code and I need to know which function does what with which variable?! Or should I just make a one big nice and happy class for all my variables and all my functions?! Because I am actually thinking about that...

[Walter Roberson]

"Is it possible to put all global variables in one m-file and make them visible in the workspace of every function?"

No. Global variables must be global'd inside each function that needs them. If the function does not have an "end" matching the "function" statement, that can be done by calling a script, or by calling a function that uses evalin('caller') . However, if the function does have an "end" matching the "function" statement then you have to code the "global" directly inside the function.

[Jan]

Okay, Ahmed, I've warned you with the intention to ease your programming. Now to your question:

A usual approach is - avoiding globals:

function G = myGlobals
G.Pi    = 3.14159262;  % Not the usual value...
G.g     = 9.80665;     % m/s^2
G.Debug = true;
end

function z = myCalculations(x, y)
G = myGlobals;
z = x * G.Pi + G.g * y;
end

Advantage: Changes of the "global" variables concern the local function only.

The standard method with globals is:

function G = myGlobals
global G_Pi G_g G_Debug
G_Pi    = 3.14159262;  % Not the usual value...
G_g     = 9.80665;     % m/s^2
G_Debug = true;
end

function z = myCalculations(x, y)
global G_Pi G_g
z = x * G_Pi + G_g * y;
end

Disadvantage: A "G_Pi = G_Pi + 1" would destroy the complete project. If the code has 50'000 lines of code and a student should write a sub-function, debugging gets the pure hell.

Using a script would work also:

% File: myGlobals.m
G_Pi    = 3.14159262;  % Not the usual value...
G_g     = 9.80665;     % m/s^2
G_Debug = true;

function z = myCalculations(x, y)
myGlobals
z = x * G_Pi + G_g * y;
% end  % Not allowed, see Walter's explanations

Note that you would be the first programmer, who can avoid typos or other bugs. The industrial standard is about 15 - 50 errors per 1000 lines of code. (I do not post a source for this claim, because it is a very rough estimation only and I trust it only, because different examinations yield the same magnitude.) Therefore I detest the code I've suggested and would not use in in productive software. Whenever I write a short hack, I keep in mind:

• If it is working reliably, it will be re-used in a larger project.
• If it is not working reliably, delete it.

Therefore it is a good programming practice to write each piece of code such, that it can be re-used in a large context.

[Stephen23]

"I understand this is horrible"

It is.

"but I have a huge code and I need to know which function does what with which variable?!"

Use the debugging tools. Plot data. Test your functions independently of each other, with test cases that cover all required types and edge cases. Keep your workspaces separate!

[Steven Lord]

Instead of putting your forks and screwdrivers either on the street or on the table, put them in a drawer. That way they're organized in one place and you can easily extract what you need.

In MATLAB, two possible types of drawers that you can use are cell arrays and struct arrays. For this I'd probably use a struct array, since it gives you the ability to (or rather requires you to) name the tools it contains. That also gets you part of the way to object-oriented code (in fact in the old object-oriented programming system, objects were structs that had had the class function called on them using a certain syntax inside a constructor.) When or if you decide to go full OO, the fields in your structs can become properties or methods of your objects.

[Ahmed Hossam]

well, I have created a (handle) class and put all variables as properties! Best way, I guess. Here is my next question:

https://de.mathworks.com/matlabcentral/answers/333914-call-a-function-in-an-m-file-from-a-method-of-a-handle-class

Answer 2

[Walter Roberson]

"I know that declaring a variable with the keyword global in each function makes a copy of the same variable and changes made on the copies are like made on the original..."

Not actually a copy: all of the local versions use the same data and metadata pointers.

"If I would like to declare all my global variables in a separate script or m-file, how should this be done?"

Put them in a script and invoke the script from each routine.

Note: this will not work for any function that has an "end" that matches its "function" statement.

This approach is not recommended !!

[Ahmed Hossam]

Thank you for your answer.

Note: this will not work for any function that has an "end" that matches its "function" statement.

... What?

[Walter Roberson]

Suppose you have a function that looks something like

function y = f(x)
  y = x.^2;

MATLAB treats that differently than it would treat

function y = f(x)
  y = x.^2;
end

The version with the "end" is needed for class definitions; it is also needed for nested functions, which are needed for shared variables. For example,

function y = f1(x)
  x2 = 2*x;
  y = fx();
  function r = fx;
    r = x2.^3;
  end
end

Notice that fx is defined inside of f1, and makes use the shared variable x2.

When you do not have an "end" matching the "function" statement, then it is permitted to run a script that creates new variables in the workspace:

define_globals.m

   global a

f2.m

function y = f2(x)
  define_globals         %legal
  y = x.^2 + a;

However,

f3.m

function y = f3(x)
  define_globals         %not legal
  y = x.^2 + a;
end

The restriction is not against calling scripts: the restriction is on the script defining new variables

assign_a.m

   a = 1;

f4.m

function y = f4(x)
  assign_a        %not legal because script defines new variable
  y = x.^2 + a;
end

f5.m

function y = f5(x)
  a = [];
  assign_a        %legal because script does not define *new* variables
  y = x.^2 + a;
end

[Ahmed Hossam]

Got that, thank you. One more question: can I put two or more functions without the end statement in the same m-file?

[Walter Roberson]

Yes. The rule is that all of the functions defined in a .m file have to be defined the same way as each other.

[Jan]

@Walter: I'm not sure, if I get the point.

.m:

function testfcn
testscript
disp(a);
end

testscript.m

a = 17;

Now calling testfcn starts testscript and afterwards 17 is displayed. Therefore I do not understand, what exactly is "not legal" here.

Defining a global inside the script works also:

testscript.m

global a

Command windows:

global a
a = 28
testfcn

28 is displayed.

[Steven Lord]

If any of the functions in a file end with an end, all the functions in that file must end with an end. So having a file like this is fine:

function f = timesn(n)
% No functions end with an end
f = @(x) myfun(x, n);

function y = myfun(x, n)
y = x.*n;

Having a file like this is fine:

function f = timesn(n)
% All functions end with an end
f = @(x) myfun(x, n);
end

function y = myfun(x, n)
y = x.*n;
end

A file like this is fine:

function f = timesn(n)
% All functions end with an end,
% and one function is nested in another function
f = @(x) myfun(x, n);

    function y = myfun(x, n)
    y = x.*n;
    end
end

Having a file like this is not.

function f = timesn(n)
% Some but not all of the functions end with an end
f = @(x) myfun(x, n);

function y = myfun(x, n)
y = x.*n;
end

See the last section of this documentation page for more information.

[Walter Roberson]

https://www.mathworks.com/help/matlab/matlab_prog/variables-in-nested-and-anonymous-functions.html

[Jan]

@Walter: You wrote above:

% assign_a.m
a = 1;

% f4.m
function y = f4(x)
  assign_a        %not legal because script defines new variable
  y = x.^2 + a;
end

This works in my R2016b, so why is this "not legal"? This works also:

% define_globals.m
global a

% f3.m
function y = f3(x)
  define_globals         %not legal
  y = x.^2 + a;
end

This runs as expected, when the global a has been defined e.g. in the command window. Therefore I assume it is "legal".

[Steven Lord]

"Poofing" variables into a workspace via eval or running a script file is rarely a good idea, as has been discussed repeatedly and at great length in Answers.

In some circumstances, poofing is allowed even if the function into which the variables are being poofed end with an end. As written, Walter's examples fall into these circumstances.

In some cases, including where the function being poofed into is nested in another function or has another function nested in it, it is not allowed. The third timesn example I posted is an example of such cases.

[Walter Roberson]

My understanding had been that poofing was not allowed in any function that was closed with an "end"; I had thought the matching "end" was enough to signal the workspace was to be a static workspace.