Coding Practice: Naming and best practices for 'overhead' variables

Hello all, I have a couple of questions regarding what I will refer to as 'overhead' variables. Examples of these would be variables controlling/identifying: the version of Matlab, whether to use a GPU because a CUDA enabled one is available, the location of a diary/log file, the current evaluation time for different parts of the script, etc.

These variables do not store data, but may be used in different ways by subfunctions during the execution of a code, and need not be retained after code execution. So:

• What is the proper name for these types of variables? Is there one? They are really controlling parameters for the execution of a set of functions, but thats a clunky name.
• Is there a best practice for handing these to a bunch of sub-functions. I am currently using a structure, and a bunch of input parsers, but this requires a fair amount of rewriting any time I modify or add a new overhead variable. I know that global variables are a thing, but avoid them like the plague. Is there a better/cleaner way of handling these in Matlab?

Cheers, Dan

Answer 1

[Walter Roberson]

Back in the late 70's and early 80's, the state of the art for programming was Edward Yourden's books on Structured Design. One of the points they made was to clearly separate State from Data. The variables you are describing would mostly have been described as State variables.

Although distinguishing between State and Data can help clarify thinking, Computing Theory, in particular Turing Machines and the techniques of Lambda Calculus, show that other than the distinguished "current" instruction, in theory State and Data are indistinguishable.

For example, in

for K = 1 : 5
  fprintf('%d', K*ones(1,K));
  fprintf('\n');
end

K is both State (row number) and Data (content to print), and there can be no useful distinguishing between those.

All of which is to say... It doesn't matter. You do not need to distinguish these as being somehow "different".

Consider your example of a CUDA variant being available. There might be use for a variable that stores that fact, but that variable is probably not what should be passed to the lower level routines. The lower level routines should either be passed a function handle that does the work "somehow", or else should be passed a flag that indicates whether to use the CUDA variant. Because even though a CUDA variant might be available, that does not mean that it should always be used. The user might know that they have a slow GPU, or the user might want to compare the results of CUDA vs non-CUDA because the user is seeing significant round-off effects.

[D. Plotnick]

Thank you. "State variables" is the term I was looking for. Your point about State and Data being practically indistinguishable is well taken, but I am still interested in ways to keep coding clean. Upon some thought, the division I am considering is closer to 3-tier.

• State - variables instantiated by the code, that govern how the code runs, but that never need to be seen/retained by the user. Example: file ID of diary file.
• Relevant Parameters - parameters set by code OR by user inputs that may be retained/viewed. I use inputParser a lot for this kind of variable. Example: the GPU flag. It will default to using the GPU if a CUDA enabled device over a certain size is available, and may be force disabled by the user.
• Data - actual input/output data that will likely be retained/viewed and must be user defined.

For the moment, it looks like my current method of passing these three categories as input structures is the way to go.

Thanks again.

[Walter Roberson]

Where do iteration counts fall into your categories? The user may well want to know how many iterations have been done so far, or might need to know that the process failed on row #83279 of the data file, which is an iteration counter.

[D. Plotnick]

Interesting question, and can see that has the same issue as your looped K example above.

I would say that the above categories apply to variables I wish to use as inputs/outputs to subfunctions, but I will often use iteration index as an input value for cellfun and arrayfun type operations, where the iteration index doubles as e.g. row index. Thus, iteration index may be used for multiple task types, including state monitoring (waitbar) and error checking/logging. It does not fit neatly into a box.

I will console myself that iteration index is rarely (with the exception of arrayfun type operations) passed between functions and thus I have little reason to try to drop it into some input/output structure for later use. It will remain one of those unfortunate intra-function variables, like outputs of "sz = size(Matrix)", that clutter my workspace during debugging.

[Walter Roberson]

I pass loop indices between functions so that the lower level functions can report on progress in a user-friendly way. For example,

fprintf('Best from phase A of iteration #%d was %g\n', iter_count, best_cost);