Naming conventions for variables [closed]

Question

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...?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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 ;)