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

Shlomi Fish shlomif at
Mon Jun 7 06:27:05 PDT 2004

On Monday 07 June 2004 15:22, Yuval Yaari wrote:
> >People should use an operating system that doesn't crash three times a
> > day.
> >
> >People should use a standards-compliant browser that doesn't have more
> >security holes than Swiss cheese. (oh wait - most of them don't).
> >
> >The Technion should teach a shell that wasn't shown to be considered
> > harmful, and isn't loathed by any half-witted UNIX hacker. (oh wait - it
> > doesn't).
> >
> >Seriously now, not all editors implement auto-completion, just as not all
> >editors have built-in functionality to read mail, browse the web or talk
> > on the IRC. (;-)) Auto-completion is not yet considered a feature that
> > every editor must have, much less a feature that all programmers use, or
> > wish to use. Maybe some years from now this situations will change, but
> > at the moment, I and many other people do not use auto-completion, or use
> > editors that do not.
> >
> >I don't think auto-completion is editor-bloat or creeping feuturism. It's
> > a useful feature. However, it's still the programmer's choice to use it
> > or need it. gvim, which I use daily, has many features that I don't
> > utilize, even though they may be useful. So is auto-completion.
> Your editor should be a mail, web and IRC client...
> It should also translate your Perl code to morse code.
> While these features exist in my editor, they are stupid and useless
> (the fact that I sometimes use them means that I'm stupid and useless...).


> Auto-completion is neither useless nor stupid.

I agree that it isn't either.

> Vim can auto-complete, and it's the most basic feature for an editor,
> and it's a pure must.

auto-completion is not _the most_ basic feature for an editor. Search and 
replace is the most basic feature. Auto-indentation is the most basic 
feature. Word wrap is the most basic feature. Save/Save As/Open/etc are the 
most basic feature.

auto-completion is a nice-to-have feature, which is useful, but still not a 
must. It was introduced rather lately in editors development. And not 
everybody use it.

> It's very useful.
> All editors have so many features that we don't use.
> Don't compare M-x doctor to auto-completion (which again, is a
> life-saver and a must for all editors and I call programmers of the
> world to use it :)).

Are you kidding? M-x doctor is much more useful than auto-completion.
(just kidding)

Seriously now, I think I'm using a very large subset of the features of joe 
when I use it. (or at least had when I seriously used it). So joe doesn't 
have so many features that I don't use. In the working environments I grew up 
with, auto-completion was not present, and so I did not get used to using it. 
Maybe now I will.

> >>Your editor is your power tool.
> >
> >"power tool"... not again! A programmer's editor is one of his most
> > commonly used tools. Whether it is a "power" tool, is debatable. Some
> > people can draw well with a computer carying a host of very feature-ful,
> > and sometimes very costy, computer graphics programs. Others can draw
> > very well by using a pencil, or editing the SVG/EPS/whatever file
> > directly. Would you call a pencil a power tool?
> >
> >Similarly some people use Emacs or some complex IDE for their editing
> > tasks, while others are using joe, classic vi, or some other
> > feature-impaired editor. A code a programmer produces should be editable
> > by all editors, not just those that have particular features.
> > (auto-completion in our case)
> I meant a power tool for programmers.
> I can't think of another way to program, please open my eyes to your
> telepathic way of programming :)

I don't have one. At least not yet. What I meant was that one's editor can be 
very powerful, or it can be relatively limited. A text file is a text file. 
You can edit it with ed, pico or repetitive bash commands if you want, and 
gcc or the Perl interpreter will still be able to process it and run it 

I was using the painter's as an analogy. I am very reluctant to call some 
editors "powertools", as they are nice, usable and bug-free, but still quite 
limited. But some poeple use them.

> >>Names should be 20 chars long, but should describe it.
> >
> >This sentence does not make sense. It's probably:
> >
> >"Name should not be 20 chars long, but should describe it."
> >
> >If so, then I agree.
> My mistake. Was it this morning when I was really late for work (I got
> here at 9:30 at the end, not THAT bad)? :)

Indeed. Does your work start at 09:00.

> >>Also, if you find that your name isn't enough, but some comment near the
> >>first decleration.
> >
> >Did you mean "put some comment". Yes, you're right about that. Albeit
> > comments are not a substitute for meaningful variable names.
> Yes I did. Again, the late-for-work-excuse.
> I agree, but they do come in handy most of the time.
> I'll explain: I always use strict. It's in my editor's Perl template
> (when I create a .pl file, it's there).
> So I always use "my" to declare variables.
> If I find $VarThatIcantUnderstand then I just look for "my
> $VarThatIcantUnderstand" and check for the comment.
> If both name isn't clear and no comments exist (or the comment isn't
> clear), I'm in troubles and I start with the digging which I hate.
> Remember - always use clean names and comments (bad English doesn't
> count) - so I would still have hair when I reach 20 :)

Right. BTW, why are you using CamelCase for variable names? Most people use
words_separated_by_underscore. (and I personally find it much more desirable).

> >[...snip...]
> ><nod />
> Are you agreeing with the infamous 1 screen law?

I'm not sure I agree with it or not. I was just nodding because I did not have 
anything to say.

> >>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.
> >
> >See, what I said earlier about auto-completion. And you can say that I'm
> > lazy enough to remember another keystroke, or to try to enable it in
> > gvim. I'm also much less reluctant to switch to a different editor,
> > because I'm used to gvim, (in my particular, highly non-conventional
> > configuration).
> NO - gvim has it, I've seen it with my own 2 eyes :)


> Though switching editors should come to your mind... (just kidding -
> even use notepad if you're used it...)

Notepad does not have auto-completion, or even auto-indentation, last time I 
checked. I installed gvim on Windows and consistently uses it for everything 
serious. It's funny that MSIE uses notepad to view the source of the HTML.

In any case:

> >As for typos, "use strict" catches most of them. I sometimes confuse
> > between two distinct variables. (with completely distinct names) In this
> > case, neither auto-completion, nor strict help.
> In this case, M-x perldb works well.
> Does the Perl debugger integrate to your editor? I think it's important
> too. Really.

Maybe it's possible to run the perl debugger from within gvim. I never really 
tried. I use either perl -d (on the command line) or sometimes ddd (but 
usually for C, and even there I mostly use plain gdb). ddd is a very 
impressive debugging front-end (for gdb, perl -d, and other debuggers). But 
it's quite heavyweight and written in Motif.

One of the most irritating things about Visual C++ is that its debugger does 
not have a command prompt. gdb is so much faster and easier (and more easily 
automated and customized). GUIs can seriously suck in comparison to CLIs some 

I happen to like command line debuggers. 

> >>>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.
> >
> >Note that I meant abbreviations, not acronyms. By this I mean using "num"
> >instead of "number", "perm" instead of "permutations", etc. As for
> > acronyms (="rashey teivoth"), they are usually Evil as variable names,
> > unless it's a well-established one. You can use "$tcp_port" instead of
> >"$transfer_control_proto_port" for example.
> I thought you mean acronyms (which I know what they are...).
> As for acronyms, as long as they exist in - I
> think it's ok to use them, though personally, I wouldn't.
> TCP and such are exceptions, of course.


> >>That's not just russian - you should know by now what these things mean
> >> :)
> >
> >I have no idea what "Naxuy Suka Blat" means.
> Curses in Russian.
> I know what "Naxuy", "Suka" and "Blat" mean, but together I don't think
> they form anything logical.

Hmmm... $laazazel_lekh_hapesh_mi_yenaanea_otkha ... ;-)

Reminds me that Joel Spolsky said a codebase he worked on once had a class 
called FuckedString:

> >>Of course, and I was just kidding.
> >
> >Heh heh.
> >/me taking jokes too seriously as always
> We all do sometimes.

But me quite often. Possibly more often than others.

> >>I'm going to be late for work if I don't stop reading mail in the
> >>morning...
> >
> >Heh heh. I read some of this discussion, before I needed to go (walk,
> >actually) to a job interview in the morning. I was still able to arrive
> > about 10 minutes early.
> See? I was late for work so I was trying to type as fast as I can.
> Reading mail before work is a bad idea.


> I hope the interview went well, good luck.

It went pretty well. It involved some discussion about Perl there, but I'd 
like to delay discussing it in public until I find out if I got the job or 
not. (they have other candidates)


	Shlomi Fish

Shlomi Fish      shlomif at

Quidquid latine dictum sit, altum viditur.
        [Whatever is said in Latin sounds profound.]

More information about the Perl mailing list