When programming, what naming conventions do you use for your variables? I don't mean when the name of the variable should be obvious; ie. sum, total, first, last. But when you name variables that don't really fit into a category/obvious structure, what sort of names do you use? Is it, myVar1 or test1 or variable1, etc...?

closed as not constructive by Walter, gnat, ChrisF Aug 2 '12 at 17:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.


There always must be a purpose for a variable, otherwise you can leave it out and you don't need a name. So use it's name to identify the purpose for a variable.

e.g. I sometimes introduce variables for the sole purpose of keeping a value that needs to be returned. I might call that variable returnValue e.g. sometimes it is a temporary for a different variable, I might use tempUserName

hope this helps.

  • 4
    +1: The only variables that don't need a name are i for tight loops, and even then I read that as shorthand for iteration (its successors j and k just play off the letter but if I'm going that deep they might deserve names). – doppelgreener Jan 4 '11 at 10:34
  • Sometimes you syntactically need a name because the variable cannot be left out (even though it isn't later used). Sometimes that name is spelled '_'. – Fred Nurk Jan 4 '11 at 11:49
  • 3
    @Axidos: I might be wrong, but IIRC, the i is a carry-over from series/sigma notation, where the i stands for index. – Steven Evers Jan 4 '11 at 15:55
  • 1
    @Axidos, Fred Nurk: Good points. Point-free style + _ can really eliminate most useless variables, and it won't be difficult finding expressive names for the rest. – Dario Jan 4 '11 at 18:19
  • What would you name, for example, the argument to ceil? – dan04 Jan 7 '11 at 9:14

For me, these are the basic rules any convention should be based on:

  1. Any convention chosen should make it easier to read the code.
    Each line of code is written once, but read dozens, hundreds, or thousands of times. So the time it takes to write a line of code is irrelevant, important is only how long it takes to read and understand a line of code. Any convention should have this in mind.
  2. Be consistent.
    The only thing worse than a mix of convention is no conventions at all, and the more conventions are mixed, the more the former approaches to the latter.
  3. Don't invent your own convention.
    Usually, you are programming as a part of a team, adding code to some project which has been around for a while. Stick to the team's or project's conventions.
    If you're doing a project alone, use a convention that's popular with your coworkers or common in your company's projects. Usually others will be joining in later or take over maintenance after you've left. Make them feel at home.
    If you are alone and don't have a team or projects to consider (how likely is that, unless you're doing stuff alone and for fun?), pick an existing convention. Prefer those which are common in whichever field you work.

The following are some specific conventions that I consider important. If I had to join a team or project where the conventions already settled upon explicitly violate any of these, I'd started to rebel and make a fuzz about it.

  1. Variables represent objects in the real world, so they should be named with a noun.
  2. Types represent categories of objects in the real world, so they, too, should be named with a noun.
  3. Functions and methods represent actions in the real world, so they should be named with a verb.
  4. Booleans should have an "is", "has", "must be" or something alike in their names. This is true for both boolean variables and functions/methods returning booleans.
  5. Don't encode types in names. Over the course of a decade of adding features and fixing bugs, types often change. It's clumsy, error-prone, and often quite impossible to change variable names accordingly.
  6. Avoid abbreviations except where they are really obvious and very common. (Yes, I know this one's quite fuzzy. Still, it had to be said.)

Whether you use PascalCase, camelCase, or the fake_space_style, whether identifiers should start with a capital letter or not, where to put braces etc., I have my own preferences about. But these I consider just that: personal preferences, easily overruled by team- or project-specific agreements.

  • Caveat to #3: Don't stick with existing conventions if they're downright wrong (e.g. something ridiculous like "all variables have to be no more than 8-characters, in uppercase, with the first three being a Hungarian prefix"). – Wayne Molina Nov 11 '11 at 19:13
  • @Wayne: If the rules are wrong, change them. You will gain nothing by inserting a few lines with a different (albeit sane) naming convention into a file, no matter how wrong the existing ones are. – sbi Nov 12 '11 at 13:20

I use snake_case for all my variables.

I try to make them nice and specific and without unnecessary abbreviation. e.g. file_id rather than fid.

If I am just testing something, I usually use the first letter of the type. e.g. If I'm in the Python interpreter, I'll use l for a list, s for string, etc.

Otherwise I give it a descriptive name.

I'm going to steal jensgram's answer for avoiding conflicts though, good idea.


Two scenarios I can think of:

  • When adding (hacking) functionality in already messy code (for some reason this happens a lot in TYPO3 extensions) I tend to prefix my variables with my initials ($jgXxx). That makes me pretty confident that I'm not introducing conflicts in PHP code that I don't even want to understand.

  • When I just need a placeholder I usually use the prefix $tmpXxx.

  • Hm.. adding initials? and what if you will work after John Goe? ;) IMHO it is only little bit better than adding timestamp to variable name. – ts01 Jan 4 '11 at 10:09
  • 1
    @ts01 Definitely not the best way, no. But it works whenever John Goe has not touched the code before me :) – jensgram Jan 4 '11 at 11:22

Every variable name should be "obvious" in the sense that it should convey the purpose of the variable in a way that's readable and understandable. Ask yourself "what does this variable represent in terms of the larger problem I'm trying to solve?" The answer to that question is the name of the variable.

Don't use names like "myVar" or "variable1"; those names tell you nothing about what the variable represents. And for the love of God, do not perpetuate the abuse of Hungarian notation that encodes primitive type information into the variable name (iCounter, szName, fRoot, etc.) if you can help it. That's not what it's meant for, and it just clutters up code and makes names hard to read.


If i really have to create variable which i do not need (because of language semantics), I use _or $_ (depends of language). AFAIR it is proposed somewhere in python's PEPs.

Otherwise, as KeesDijk stated, every other variable has a purpose and should be named adequatly.

If you have a convention to follow (one very common is to use i, j, k for loops, others can include names such as tmp, swap etc) stick to it.

Personally I prefer not to use names like tmp - they are not to descriptive. Use something more clear, like 'rest_to_send', 'last_data_pointer' or 'current_vertice' instead ;)

  • what do you call your temporary variable when you implement a swap? ;) – João Portela Jan 5 '11 at 12:15
  • well, there are swaps and swaps ;) And I didn't say that I use 'tmp' for swapping. Rather swap as name of variable like tmp or current – ts01 Jan 5 '11 at 18:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.