naming convention of temp local variables

Question

What is the standard way to name a temp variable in the local function? let me give you an illustration of what I am doing. I get a pointer to a structure, so I want store one of its members locally to avoid a de-referenced, and then any modification assign back to the pointer.

To be more concrete:

struct  Foo
{
  double m_d;

};


void function (Foo* f)
{
   double tmp=f->m_d;

       /***Other stuff***/

     f->m_d=tmp;
}

I don't like tmp. If I have many of them in a function, they only add a confusion.

Thanks

Answer 1

Do the same thing you would for any other variable: Give it a concise, expressive name. How about using the original name of the member variable you're copying (possibly leaving off the m_)? That's the best way to make the connection between the two explicit.

Answer 2

What do you store in the tmp variable? Use that description as a variable name, if it isn’t too long. For three-line functions (swap …) tmp is just fine. For almost everything else, be descriptive.

Answer 3

I would call it saved_m_d, or simply m_d (but then, I would also give m_d a different name).

Answer 4

I use m_ for member variables and do not use any prefixes for the local variables. So in this case it would be double d;

Answer 5

If a more descriptive them can't be thought of, the convention we practice at work is to use the name "my[object]" in lieu of a better name. Above all, make it descriptive so that your code is easier to understand and maintain. Self-documenting code is another benefit of doing this.

Answer 6

There are some 'frequently used shorthands', such as i,j and m and n for loops, but if you are going to have many loops in a function, it's probably best to have something more expressively.

I would use the rules for good variable naming for most cases. If you are doing C++, the question I think is 'how am I going to differentiate member variables' instead of local variables.

Answer 7

Linus Torvalds - Linux Kernel coding style from Linus Torvalds :

LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome.

Answer 8

In general, I just use descriptive names. If it's an attribute, I make the first letter uppercase and apply camel-casing. For local variables, I keep everything lowercase. For variables that store attribute names, I use lower-case with an underscore as prefix. I avoid using any shorthand notations and generally don't need shorthand either. Code Completion is very useful with long names. :-)

Several IDE's will use Code Highlighting which is practical if you need to know if something is a class or variable. Thus I don't make many differences between class names and attribute names. (Except in Delphi, where I still prefix every class with a T since that's a standard convention in Delphi.)

And no, I don't use tmp. I write it out as Temporary, just in case I can't come up with a different name. Or I, J, K, L or M in case of index-numbers. (No, just those 5 letters, always uppercase.) In your case, I'd use "oldvalue" or "oldm_d" instead.

Answer 9

For your information: Code Complete has a chapter decicated to variable naming.

In your example one problem is that the member variable in Foo is not very descriptive to start with, which makes it hard to find a useful name for the placeholder local variable.

For example, I would do something like this:

struct Foo
{
  double mValue; // I don't use underscores here
                 // however, you can do as you please.
                 // Also 'mValue' is just for the sake of example,
                 // you should find a more descriptive name :D

};


void function (Foo* f)
{
   double oldValue = f->mValue;

       /***Other stuff***/

   f->mValue = oldValue;
}

Answer 10

I'd say try to find something that most specifically describes the purpose of the variable and at the same time distinguishes it from any other variables used in that function.

So, assuming that "d" actually represents some name that already describes the meaning of your variable, then I'd go with something like cached_d or copied_d. That way you can have more (cached_a, cached_b, cached_c, etc) without confusion among them.

And then I would further suggest including a comment that states specifically why you made that local copy. Perhaps something like:

double cached_d = f->m_d;   // cached to avoid further de-referencing

That way anyone looking at that code in the future should have no problems figuring out what you're doing and why.