The worlds two worst variable names

[Roland_Yonaba]

By Andy Lester : Here

[ivan]

Cool article. Although I have to disagree that ALL variables need to be descriptive.
Especially with temp/local variables I find it easier to use 'local a =' or 'local x1, y2 =', etc.
It just makes the code shorter compared to descriptive variable names.
Naming classes, on the other hand, I find to be much more tricky.
Seems like bad class names suggest bad OO design.

[Roland_Yonaba]

Cool article. Although I have to disagree that ALL variables need to be descriptive.

Dummy variables...

Code: Select all

for _,v in pairs(t) do
...
end

[Inny]

Since very small functions are so easy to make in lua, it's fine to use a, b, c, i, j, s, t, x, y, z, and _ as variable names. But then, it's important to have descriptive function names. Things like init, load, update, draw, refresh, keypressed are fine for function names, but then we need descriptive class names. We get into a bit of an infinite regression there, but luckily your program is done when it's about to become a problem. Anyone want to go out for ice cream?

[Camewel]

A good variable name is short, easy to remember and tells you what it does. Data ticks two of these boxes, so it's not bad. The worst variable name would be some 200 character long spew of random letters and numbers. As long as you know what it does, it's not actually a problem, as the program is hardly going to complain that your source code has badly named variables. But anyway, ice cream sounds good.

[kikito]

A good variable name is short, easy to remember and tells you what it does.

I don't quite agree. I would not put "it should tell you what it does" in the last place, but in the first. I don't think "being easy to remember" is a needed quality. I'd rather be it so obvious that I don't need to remember anything at all. Regarding the length, I think it's nice it's possible to find a small name, but it's not the most important thing.

A good variable name is as short as it should, but not shorter. Sometimes a one-letter 'i' is ok. But other times 'aSomewhatLongName' is needed. But how do you decide how short it should be? That's actually an interesting question.

This is a subject I care a lot about. There are books written about this. Robert C. Martin's "Clean Code", has a whole chapter (Chapter 2) dedicated to proper names. Here's an extract:

• Use intention-revealing names - pretty much what Camewel said: "names should tell you what their variable does".
• Avoid disinformation: If something is not a List, don't call it somethingList or ListOfSomethings. Beware of variable names that vary very little. Use consistent spelling.
• Make meaningful distinctions: If two different concepts need the name "sprite", don't just add numbers (sprite1, sprite2 ...). Add something that is intention-revealing: marioSprite, princessSprite. Don't use noise words like "info", "data" or "object" to make that distinction.
• Use pronounceable names: goblinEnergy is better than gblnEn, even if it's longer. That's because the human brain is good with words. Pronounceable names are great when we have to talk about the code with someone (even our future selves).
• Use searchable names: one-letter variables are very difficult to find with an editor. If a concept is important, make sure that you can find it quickly with your editor's search function. This is one of the reasons why MAX_ENERGY is better than 7.
• Avoid encodings: beginning integers with i, strings with s, etc. It's just not worth it. It makes the variables less pronounceable and longer. Don't prepend the letter "m" to "members" of a class.
• Avoid mental mappings: 1-letter variables are ok if someone reading your code does not have to be "mentally changing" its name to something else. This is why it's ok to use 1-letter variables in small loops with just 1 or 2 lines, where the variable is used only once. But when the loop gets bigger, you should use a longer variable name so the reader doesn't have to remember that "i is in reality the index of the current frame" (just call it frameIndex).
• Use verbs on functions: isBoolean() is better than boolean(), activate() is better than active(). You are already using names for the "objects". Use verbs in your methods, so the code reads more like natural language. If you list a table, you can differentiate the methods from the attributes just by looking at its names.
• Don't be cute. If your game has teleporter tiles, don't call them "Scotties". Call them "teleporters". Also, use simple English terms. Don't say "whack" when you can say "kill" or "destroy".
• Pick one word per concept: Don't say "get" in some places, and "fetch" in others, to do the same thing. Pick one word, and use it consistently.
• Don't pick the same word for two different concepts. In your app, "add" should mean just one thing - for example, insert at the end of a collection. If you are trying to create a method that inserts in the middle, don't call it add.
• Use computer science names. If you know you are implementing quicksort, and that usually names variables "left" and "right", don't invent new names for those; just use "quicksort", "left" and "right".
• Use problem domain names. If the problem you are resolving has a fixed terminology, use it. For example, if you are doing trigonometry, it's ok to use mathematical terms to name things - call the sine sine, not s or f.
• Add context when needed. If you see "energy", "position", "lasers" and "shields", it's pretty clear you are speaking about a spaceship. If you have "energy" alone in one function, it might not be so clear that it refers to a ship's energy. Try to pass the whole ship as parameter if possible (so you can do ship.energy). If you can't, precede the parameter name with "Ship" - shipEnergy instead of just energy.
• Don't add superfluous context: If your game is called "Super Wario Words", you don't need to precede all your classes with "SWW".

Sorry for the long post - I'm trying to synthesize a whole chapter of the book. Which is very good, I recommend it, even if you don't program in Java (I don't).

[Jasoco]

What about using "Mob" when you mean "Enemy" or "NPC" or "Animal"? Personally I like to think of my games as plays and the stuff on screen as scenery and actors.

[Camewel]

'Mob' is a widely accepted term already. The problem is only really when you use local slang terms.

[Inny]

What about using "Mob" when you mean "Enemy" or "NPC" or "Animal"? Personally I like to think of my games as plays and the stuff on screen as scenery and actors.

Mob is short for Mobile, and tends to be a common inherentance between enemies, animals, npcs, etc., so that's kind of what you're setting the expectation for when you use that name. Actor is a good term also, because it's actually a computer science term, and means an object that responds to messages and operates in a way that's conducive to concurrency.