List all variables in a mfile

Is there a way to list all the variables used by a mfile? Here is the scenario: I am editing a legacy function which takes in some input structures and then expands the structure fields into variables within the function workspace. But, I don't have an example of the input structures, so I will have to recreate them, which means I must first identify what their fields and hence the variables in the function are. Because I don't know the input fields, the function won't run, so I can't use the profiler or other tool that requires a working function to identify the variables. If the whos command permitted a mfile as the 'location', that would be perfect...

[Sean de Wolski]

And that is why we recommend against "poofing" variables...

[Jan]

Taking an input struct and assigning the fields to local variables dynamically is obviously a really bad idea. I cannot image a better way to confuse users and the Matlab interpreter, MLint and any automatic code analysis - except sorting the charatcers of the program alphabetically and storing the sorting order run-length-encoded instead of the clear source code.

Ask the author and call him names.

[Image Analyst]

I don't see anything wrong with it if it makes it more convenient. For example what's wrong with

storedStructure = load(fullMATFilename);
userSettings = storedStructure.userSettings;

(By the way, don't use settings for a variable name if you have R2012a or later - I found out the hard way that settings is now a reserved word.) MLint and the interpreter won't get confused about userSettings at all. I know they don't because I do it.

[K E]

The author doesn't have the info (code is old), so I will just fish the variables out of the code lines. If the code was a Simulink mdl instead of a mfile, I could locate the variables using findVars - which exists precisely because the default way to run Simulink is to poof variables into/out of the workspace!

Answer 1

[per isakson]

I think it is possible to do automatically. Idea:

• set a conditional break point at the last line of every function. Hopefully there is the word, "end"
• the "condition expression" should always return false
• side effect: run evalin( 'caller', 'whos' ) - something like that - assignin(?)
• no new code in the system under study is required

I've done something similar in tracer4m.

Matlab PUBLISH uses side effects of conditional break points.

[K E]

Creative, I will give it a try.

[Jan]

A good idea. For really clean code this will work sufficiently. But unfortunately the question sounds, like the code is not programmed in s a strict style with respect to reliability. E.g. something like this will let your method fail:

if rand > 0.5, disp = 13, end
k = @fcn, if rand > 0.5, k = 17; end

Any clear command will cause troubles also. So finally after the automatic analysis, the manual control of each line is still required.

PS. I've reviewed a function today, which would let evalin('caller', 'whos') fail, because whos was a local variable. :-(

However, this is the most promissing automatic approach, and less depressed than my "better re-program everything".

Answer 2

[Jan]

Taking an input struct and assigning the fields to local variables dynamically is obviously a really bad idea. I cannot image a better way to confuse users and the Matlab interpreter, MLint and any automatic code analysis - except sorting the charatcers of the program alphabetically and storing the sorting order run-length-encoded instead of the clear source code.

Ask the author and call him names.

There is no secure way to distinguish local variables and built-in functions:

S.disp = 100;
myCruelFunc(S);

function myCruelFunc(S)
assignAsVariables(S);
disp(1)                   % <-- What do you expect here?!

function assignAsVariables(S)
field = fieldnames(S);
for i = 1:numel(fields)
  assignin('caller', field{i}, S.(field{i}));
end

In some Matlab releases the output of "disp(1)" even denpends on the current debug status: With a breakpoint "100" is replied (disp is a variable), without any breakpoints you get "1" (disp is a function).

Therefore expanding the structure fields into variables within the function workspace is a bad idea. I'm afraid an exhaustive analysis of the function will need more time than reprogramming it in a clean way. Simply use the fields of the struct, or expand the struct explicitely:

...
disp = S.disp;

Then MLint, code-analysis and efficient processing is possible.

[K E]

Yes, time to cut bait and just clean up the code. I will start with a parent script that assigns each variable its value, comments what the variable is, and says what its units are. Elements of Matlab Style offers such nice guidelines on this sort of thing...

[Image Analyst]

Seems like you're going to spend way more time on that than just manually inspecting the code. In fact, you'd be done by now if you had done that first instead of asking people for an automatic way.

[K E]

Well put. But I have to do this just often enough that I may automate it eventually.

Answer 3

[Image Analyst]

I don't think so, or else fdep ( http://www.mathworks.com/matlabcentral/fileexchange/17291) would have listed them. Why can't you just look at the source code? You can search for all "." to find structure references. Then just make a note of all the members that each structure uses. Shouldn't take too long to do it manually like that.

[K E]

Wish this were possible, but after the input structures are passed in, each field is automatically used to generate ('poof') a variable with that field's names and variables into the workspace.

[Image Analyst]

Not sure what you meant when you said "this" but the manual method I recommended is possible.