Steve on Image ProcessingApril 9th, 2010A practice that doesn’t make me cryAbout a month ago, Doug posted a list of 10 MATLAB code practices that make him cry. (Not a pretty sight, I promise you.) One of the bad practices was using the name of a MATLAB function as a variable name or the name of your own function. This caught my eye because I've seen this advice often given, and yet I so often ignore it. Specifically, I never worry about whether one of my variable names is the same as some MATLAB or toolbox function; I'm perfectly happy to name a variable diff, for example. And yet it never causes me trouble. In fact, you're supposed to be able to do this without trouble in MATLAB and many other programming languages; scoping and binding rules are designed to make this sort of thing work. Doug's post and some of the subsequent comments, though, reminded me that people, including experienced MATLAB users, do often report being tripped up by this. It made me start to wonder if I'm doing something different than those who run into variable name / function name confusion. After thinking about it a bit I formulated a hypothesis. Most of my work with MATLAB involves writing functions. I don't often write scripts, except when I'm writing something for the blog or preparing a demo presentation. And my functions are generally quite short and do just one thing. (That's a habit I learned the hard way—by having to maintain code that I wrote 15 years ago.) Variables inside a function exist only during execution of the function; they are automatically cleaned up and disappear when the function finishes and returns to the caller. Function variables simply have no effect on anything outside the execution of that function. It's different if most of your MATLAB workflow involves repeatedly writing and running scripts. Any variable created inside a script that you run from the MATLAB prompt hangs around in the base workspace forever, unless you clear it or quit MATLAB. I can imagine that if you're doing that all day, having scripts that create variables with the same name as common functions could definitely cause puzzling problems. You could run a script that makes a variable called diff, then move on to some data analysis and plotting steps, then go off to lunch, then come back in the middle of the afternoon and run a different script that tries to call the function diff, and boom, it doesn't work. MATLAB thinks you're trying to index into the variable diff, which you forgot you even made. What do you think of my hypothesis? If you've been burned by naming a variable the same name as a function, was it in a scenario when you were writing and running scripts? 
8 Responses to “A practice that doesn’t make me cry” |
|
|||
|
These postings are the author's and don't necessarily represent the opinions of The MathWorks. |
I recently had a student who wrote a function called “eye.m”. One week later, she wanted to do a linear regression using “regress”, but it gave a strange error. It turns out that “regress” calls “eye”, and since “eye.m” was in her current directory, this is the “eye” that was called.
James—I understand. It definitely makes sense to avoid having multiple functions with the same name on the MATLAB search path. I was thinking more about the naming of variables.
Those of us who have been using MATLAB for years have a pretty good mental catalog of the many built-in functions so it’s easy to avoid accidentally redefining a built-in function. For those lacking such a mental catalog, one helpful trick is to check if the name is already defined using “which”. E.g., looking for a variable to use as an iterator:
Ah ha, k is not already defined, now we’re good to go.
On the topic of short focused functions, do you find it better to have many subfunctions in a single larger or a many individual functions?
On the topic at hand, I find it helpful to append my variables with a unique identifier for that script/use. That way I keep them separate from built-in function and variable names, but still they’re descriptive enough for me to remember what it does.
Hi,
I think you may be right. A lot of people have been working to make things work; and you may use function names to your variables.
The point is in my mind for the reader itself and not for the machine. If you create a function and never get into it any more there won’t be big deal about it.
But if you have to read people’s code, especially if it is quite complex, or even work on one of your old work you might be confused by names.
You won’t, I’m sure because you’re used to it, but it is easier to get into people’s code without wondering, am I using the function, or the variable?
You can do without it, what is the real reason to call a variable diff when you could have named it a_diff, f_first or thousands of other things?
MatLab should accommodate this practice since there must be some rare good reasons for it. However, just because users can do something, doesn’t mean they should.
By far the biggest challenge in software around here is maintainability. At points in the future, others will review the code to understand what it does. Is there any possible situation where, for example, using eye or sin as variable names helps the user understand what the code is doing?
I am a fan of Dykstra who wrote to the effect that the primary responsibility of a programmer is not just to write code that comes up with the correct answer, but to write the code in such a way that it demonstrates by inspection that it is doing the correct calculations.
It sure seems to me that using standard MatLab, existing function names as names for my own functions or variables will obscure the code.
I only wish the MatLab development environment provided improved capability for identifying inadvertent use of this technique.
Airballman and OysterEngineer—Thanks for your feedback. It convinced me that I really did not explain myself very well. See my April 12 follow-up post.
Dave—If I don’t think a function will be useful on its own, by either the user or another function, then I tend to go with subfunctions.