Variable Naming [was Re: [] catching $a, $b unnecessary my and maybe other things]

Yuval Yaari yuval at
Sun Jun 6 23:15:16 PDT 2004

Shlomi Fish said:
> On Sunday 06 June 2004 20:48, Yuval Yaari wrote:
>> I said:
>> > 1) I thought it's obvious. I've read about it so many times.
>> > Personally, I hate people who give names like $a and $b (though I
>> did it a few times and noticed that problem - but don't tell
>> anyone). But it's a well known... bug (?) in strict because of
>> functions such as sort.
>> >
>> > 2) Did you try use diagnostics; ?
>> > Also, use strict; use warnings; and/or use diagnostics; do not
>> replace re-reading your code, or debugging it.
>> > Though they usually solve all of my problems :)
>> use diagnostics; didn't work.
>> Keep us updated if you find something...
>> As for what I said above, I don't really hate people who use $a and
>> $b, I just prefer normal names for variables (and for crying out loud,
>> your editor should auto-complete it for you so you write once and M-/
>> later [sorry for being emacs-specific]).
> Well, naming variables is something that requires some thinking. For
> once, I  disagree that giving variables long names is a healthy
> practice, just because  your editor has auto-completion. You can't rely
> on the editor having that  (joe, classic vi, etc.), and extremely long
> variable names make the code more  difficult to read because less code
> can be fit on one line.

A programmer should use an editor with auto-completion.
Your editor is your power tool.

Names should be 20 chars long, but should describe it.
Also, if you find that your name isn't enough, but some comment near the
first decleration.

> While I agree that it is not a good idea to name one's variables "a" and
>  "b" (especially in Perl due to this known limitation), I sometimes use
> $i and  $j as indexes, because it's a well-acknowledged convention that
> they are  such. In Matlab, OTOH, using "i" and "j" is possible, but
> would cause you to  lose the imaginary numbers unit (as in the complex
> number 5+6*i), so one has  to resort to "a" and "b" or some similar
> convention.

I once read, and I agree with it ever since, that if the scope of your
variable is 1 screen (visuaully, that is) or less - you can name it any
way you want.
I too named some vars $i, $j, $tmp, $idx - but you could see their
decleration and demise (I usually add undef($var) on purpose so I'd know
when a variable should not longer be used, or else "strict" comes in) in
the same screen.

> Generally a variable name should be long enough to convey its meaning,
> but not  long enough to take a lot of screen real-state, and be hard to
> write. You can  hunt me down and shoot me if you want, but I never tried
> to enable  auto-completion in gvim, albeit when working in MS Dev
> Studio, I found it  relatively useful. (albeit not something I couldn't
> live without).

Auto-completion is a must.
Not only because I'm lazy (I am, that's why I use Perl!) - but it makes a
lot of [even all] typos go away.
My editor auto-completes Perl functions aswell as already written words.

> Generally, using abbreviations for variable names is a good idea. They
> make  the code flow better.

I disagree.
Maybe if you put a comment on the 1st decleration.

>> I also know a russian programmer who named his variables
>> $NaxuySukaBlat, etc...
> You mean he used Russian for his variable names? Ouch. It reminds me of
> an  implementation of Freecell that contained a solver I encountered
> once. It was  written for gtk, GPLed and all, but when I looked at its
> source code it was  completely in French! (comments, variable and
> function names - the works). I  did not try to make sense of it.

That's not just russian - you should know by now what these things mean :)

>> But at least strict would work for him in such case :)
> Strict, yes, but not non-Russian speaking reviewers and
> fellow-programmers.  And compatibility with them is more important than
> using strict.

Of course, and I was just kidding.

I'm going to be late for work if I don't stop reading mail in the morning...


More information about the Perl mailing list