Steve on Image Processing

April 12th, 2010

More about variable names inside functions

Last week I wrote that I do not normally worry very much about whether a variable name inside a function I'm writing might be the same as the name of a function somewhere else. Unfortunately, I bungled my point so badly that some readers felt it necessary to make sure I understood the value of writing readable code. Hmph. Of course, I didn't help things by thoughtlessly choosing the MATLAB function diff as an example. It's quite unlikely that I would actually use diff as a variable; it was just the first function name that came to mind when I was writing my last post.

Let me try again, and this time I'll explicitly consider readability.

I've been using MATLAB for more than two decades, but I don't know all the functions in MATLAB. When I write a function, do I use which every time I name a variable in order to make sure there's no other function with that name? No, of course not. Who wants to program that way? And I don't need to, because MATLAB is like just about every other programming language in that it allows you to use a name locally even though someone might have used the same name somewhere else.

Also, users of my functions have probably written their own functions, and I can't possibly know what function names they have chosen. Fortunately, it doesn't matter because of the way variable name scoping rules work.

Without these scoping rules, we wouldn't even be able to safely choose readable variable names. The functions I have put into MATLAB and Image Processing Toolbox have been used by thousands (hundreds of thousands? millions?) of people. If I really had to be sure that the variable names in my functions did not conflict with any functions that those users had written, then I wouldn't be able to use readable variable names at all. I'd probably have to use variable names that look more like hash codes:

A_3858f62230ac3c915f300c664312c63f = eye(3);

If your normal working routine involves writing and running scripts, then I agree with the oft-given advice to be careful about choosing your variable names. In particular, don't use the names of common MATLAB functions.

But variables inside functions live a short, controlled life. Write compact functions with a minimum number of conditional branches, and choose your variable names to help the code reader as much as possible. And if the readable variable name you choose happens to have the same name as some other MATLAB function that's ever been written, or that will be written in the future, that's OK.

14 Responses to “More about variable names inside functions”

  1. Airballman replied on :

    Hi again :)

    I think I got your point now. I’m sorry if I was wrong in the last post, I think this reup was necessary :)

    You are of course right in everything you wrote up ahead.
    But I think that presented this way, people would just not even know that their variable as a function name.

    Noone would expect you to know every function of Matlab (at least I hope so :D), and as a common user I think I must already have one day or another used the same name as built-in functions.

    I think the real idea is simply that it is commonly advised to avoid naming variables as functions you usually use.
    Especially for beginners, that would not think about the “life time” of variables. And I was one of them not so long ago.
    When you are coding an algorithm you just wrote on a paper i may sound seducing as increment in loops :D

    To finish, diff in one of my favourite variable names when I work on images :)

    I’ll see the functions you’re talking about in the post, perhaps would you then have billions visitors :D

  2. Steve replied on :

    Airballman—Thanks. Sounds like we’re on the same page.

  3. Richard replied on :

    I completely agree with you, it is often detrimental to the readability of code to concoct artificially complex variable names to avoid clashing with builtins. The way I usually write code when developing experimentally is to have all of the code that actually does anything in functions, with a master script in cell mode to run pieces individually.

    One thing that I frequently do that raises the ire of some of my colleagues is to use i, j as loop variables.

    One exception though is when teaching/learning. I teach Matlab to undergraduate engineers, and it usually takes them a while to get the hang of scoping — in particular the differences in scope between scripts and functions. So I usually caution students to avoid using existing function names as variable names (if they are aware of it), because generally when they do, they don’t do it intentionally, leading to some interesting debugging experiences.

  4. Steve replied on :

    Richard—Sounds like a good approach. I’ve been known to use i and j as loop variables, particularly when i and j are used in whatever source material I’m following for algorithm details or mathematical equations.

  5. Petter replied on :

    i and j are too good names to be reserved for the imaginary unit. We have the perfectly fine “1i” for that.

  6. Steve replied on :

    Petter—Agreed. The advice about not using i or j originated many years ago, before the 1i syntax was available in MATLAB.

  7. Tom Palmer replied on :

    Totally agreed, by the way.

  8. OysterEngineer replied on :

    Well written elaboration.

  9. Mark Shore replied on :

    “Write compact functions with a minimum of logic, and…”

    Might I recommend changing “minimum of logic” to “minimum number of logical operations”?

    Regarding the comment about i and j, I have to fight my tendencies to use them for temporary indexing variables. Couple the default assignment of i and j with the fact that lower case “L” looks too much like the number 1, lower case “o” looks like a subscripted zero, uvw are often used for directional cosines and xyz for orthogonal coordinates and you’re left with a pretty small set. ii and jj just look odd.

  10. Steve replied on :

    Mark—Thanks for the wording suggestion. I changed “minimum of logic” to “minimum number of conditional branches.”

    Why do you feel the need to avoid using i and j for temporary indexing variables?

  11. Mark Shore replied on :

    My assumption is that sooner or later I’ll want to use i for complex numbers, so keep it reserved that way. For use in a short function I suppose this is less of an issue, but I usually use scripts. I have to discipline my untrained spaghetti code practices however I can.

  12. Steve replied on :

    Mark—That makes sense.

  13. OysterEngineer replied on :

    I think that code that uses i or j for the complex unit is very compact & clear. So, I like to reserve i & j for this.

    Like Mark, I struggled a bit with choosing an alternative for temporary indexing variables. Although I have adopted ii, jj, kk, etc., I am concerned that this will confuse novice users who read my code. It doesn’t seem like a perfect choice, but it seems the best option. Users seem to quickly engage with this style & I haven’t suffered from this choice. I guess I’ve moved beyond the stage where it looks odd.

    What are the best techniques for users who want to avoid using built-in MatLab function names for their variables? Is manually running “which” really the best option? Depending on the dynamics of your typing style, I suppose that the Function Hints will provide some indication that a variable name is an existing function. But, I find that I tend to ignore the “helpful” suggestions as a bit of background noise & don’t pay much attention to them.

    Even though this is a productive discussion of coding style, I am eager for you to return to the subject of more FFT details.

  14. Steve replied on :

    OE—I’m afraid I don’t have a suggestion for an easy way to get quick hints on existing function names.

    Thanks for the encouragement about continuing with the Fourier transform series. Those posts take me longer to write than most other topics, so when things get particularly hectic for me, like it did this past month, it’s harder to keep them coming.

    But I will definitely pick it up again soon.


MathWorks
Steve Eddins is a software development manager in the MATLAB and image processing areas at MathWorks. Steve coauthored Digital Image Processing Using MATLAB. He writes here about image processing concepts, algorithm implementations, and MATLAB.

These postings are the author's and don't necessarily represent the opinions of The MathWorks.