16

I wonder if it is good or bad (or does not matter) if I reuse the variable names as much as possible? for example

int main(void){
  //...
  int x=0;

  //..
  x = atoi(char_var);

  //..

  for (x=0; x<12; x++){
   //...
  }

  //..
  x = socket(...)
  if(x<0){
  //...
  }

  for(x=0;x<100;x++{
  //...
  }

  return 0;
}

Another variables could be used instead of x above (might be better for readability), but I wonder if it would provide me any benefit for the binary size, performance, or anything else?

Johan Elmander
  • 497
  • 2
  • 6
  • 11
  • 9
    for most cases it's bad. each variable should play its own role – Andrey Chernukha Jul 26 '13 at 14:43
  • @AndreyChernukha What about a mere counter (e.g. `i`) – m0skit0 Jul 26 '13 at 14:44
  • 1
    @m0skit0 i said for most cases, not for all – Andrey Chernukha Jul 26 '13 at 14:45
  • 1
    Using the same variable as a socket and a loop counter surely doesn't improve the readability of your code. Using meaningful variable names is also considered a good practice. – zakinster Jul 26 '13 at 14:45
  • possible duplicate of [is it acceptable to recycle or reuse variables?](http://stackoverflow.com/questions/9089961/is-it-acceptable-to-recycle-or-reuse-variables) – Caleb Jul 26 '13 at 15:12
  • @AndreyChernukha I was not critizing your comment but wanted your opinion about it. – m0skit0 Jul 26 '13 at 17:49
  • My take on this is that you should minimise the **scope** of an identifier - i.e. the amount of code wherein that identifier is relevant. (This actually goes for any identifier, like function names. Minimising their scope means reducing coupling.) This implies that reusing a loop counter name is fine when the loops are short, and you can easily see where the scope of the counter variable starts and ends. This also implies that if you have a function with several large loops reusing the counter name, this becomes bad again. (Although there are other reasons why you should avoid this.) – millimoose Jul 29 '13 at 13:08
  • You should use a variable for what it MEANS. And the variable name should be chosen to reflect a meaning for the value contained therein. A good compiler will recognize the "scope" of a variable and will reuse the space for multiple variables if their scopes don't overlap, so there's no advantage to reusing variables. – Hot Licks Jul 29 '13 at 22:46
  • To put it another way, regardless of the details, NEVER put a value in a variable that implies something different. Just because there's an "apples" variable there and not being used, do not put oranges into it. – Hot Licks Jul 29 '13 at 22:53

9 Answers9

23

In general it's very poor practice to reuse variable names for different purposes - if someone else needs to maintain your code later on the person will have to find these "context switches" in your code where x now suddenly means something other than what it meant before that line of code.

You may get some memory savings but that's so small compared to the problems it introduces that it's advised against. (Read the edit below, too.)

Typically it's also recommended not to use 1-character variable names for other than loop counters. One could argue that x could also be an X coordinate but I'd use some prefix or a longer name in that case. Single-letter variable names are too short to give meaningful hints about the purpose of a variable.

Edit: as several comments (and some of the other answers) pointed out, the potential memory savings (if any) depend on how good the compiler is. Well-written optimizing compilers may realize that two variables have no overlapping lifetimes so they only allocate one variable slot anyway. The end result would be no run-time gain and still less maintainable source code. This just reinforces the argument: don't reuse variables.

xxbbcc
  • 16,930
  • 5
  • 50
  • 83
  • 5
    I don't think i for index is that bad. – Jiminion Jul 26 '13 at 14:51
  • "You do get some memory savings" -- not if the compiler is good enough. Most compilers will optimize away a set of local variables that are each used over a different part of the function. – cdhowie Jul 26 '13 at 14:51
  • @Jim For a loop counter / index it could be ok, although I usually use something like nIndex even for indices. I only ever use single-letter names for loop counters because of the above reasons. This also depends on personal practice to some extent. – xxbbcc Jul 26 '13 at 14:52
  • @cdhowie Yes, you're right. I didn't write it that way because the _programmer_ will perceive it as a saved slot. Also with reused variables it's unlikely that the entire variable could be eliminated. One would have write the code very carefully for that which is - in itself - a source of bugs then. – xxbbcc Jul 26 '13 at 14:54
  • Do you re-use variable names the are declared in separate loops? Many are getting around this issue with declaring as local to the operation(s) as possible. – Jiminion Jul 26 '13 at 15:00
  • @Jim Yes, I do reuse loop counters and I always declare them locally in the `for` loop. As cdhowie pointed out, these are recognized by the compiler as non-overlapping variables so only one slot is allocated for them. I may also - rarely - reuse other names but they're never for different purposes. So if an `int` is allocated as a counter, that name is only used as a counter. In general I avoid doing this, though - I prefer using long, distinct variable names. – xxbbcc Jul 26 '13 at 15:06
  • @cdhowie It's not even if the compiler is "good enough". If you've taken a compiler construction course you know that the IR the compiler uses to actually generate code is programming-language agnostic, and has "variables" for every single subexpression. (Every `(lvalue, operator, left operand, right operand)` tuple.) Doing this sort of optimisation is a fundamental step of how compilers work and you can bet that unless you disable optimisation, every compiler written for production use will do the right thing here - since they need to save the stack space used by **all** the code. – millimoose Jul 29 '13 at 13:19
  • @xxbbcc I'd recommend just nuking the "you save memory" sentence since it's patently wrong. – millimoose Jul 29 '13 at 13:22
  • @millimoose I'll add a note but I disagree with your comment. It's easy to construct realistic examples where reusing a variable would end up saving a memory slot. Your comment assumes optimizing compilers (true for C) but the issue is more generic in my opinion. – xxbbcc Jul 29 '13 at 16:52
  • @xxbbcc My comment assumes any compiler written after the Dragon Book was written, and patterned after it. As in, a compiler that does NOT optimize this away would have to written by a CompSci sophomore that was missing in compiler construction class for a third of the year. It would have to be **egregiously** naively written and would end up **ridiculous** amounts of stack space. – millimoose Jul 29 '13 at 19:25
  • @xxbbcc My point is that the same "optimisation" that reuses space for local variables handles reusing space for intermediate subexpression values. There are several times more of those than there are of locals. So while you can imagine compilers that do not do this (i.e. `gcc` with `-O0`), for all intents and purposes they do not exist in practice. This optimisation is fundamental enough that you can consider it a basic feature, only *slightly* more advanced than register allocation. (And the implementation technique is similar.) – millimoose Jul 29 '13 at 19:29
  • @millimoose I was talking about compilers like Actionscript, etc. that don't (or unlikely to) do this kind of optimization. – xxbbcc Jul 29 '13 at 21:28
  • @xxbbcc First of, [citation needed]. Remember that Adobe contributed the ActionScript runtime to Mozilla of which the JIT ended up in SpiderMonkey. [SpiderMonkey uses SSA for its intermediate representation](http://en.wikipedia.org/wiki/SpiderMonkey_(JavaScript_engine)#IonMonkey) - with SSA, reassigning an existing variable leads to the same IR as using a new variable, and more likely than not SSA implies the use of linear scan register allocation. Now, it's not conclusive, but it's not implausible that the ActionScript runtime is comparably advanced to other JS runtimes in this regard. – millimoose Jul 29 '13 at 22:40
  • @xxbbcc Basically, it seems you're grossly underestimating the abilities of production-grade compiler writers, especially considering that register allocation based on variable liveness is a problem tackled in third-year college courses, not something you need to pore over academic papers for. It's not a *trivial* problem, but difficulty-wise it's on par with many other things they absolutely must do. So I stand by my claim that it's not necessary for the compiler to be "good enough", it has to be "not pretty damn terrible enough". – millimoose Jul 29 '13 at 22:42
  • I used to make an exception for "i" as a loop index, etc, vs having to have multiple distinct loop index names. But most modern C compilers allow you to declare a loop index in the `for` statement and limit its scope to that, so you can reuse "i" while still declaring it anew in each loop. – Hot Licks Jul 29 '13 at 22:49
  • And I'd agree with the others that any "production grade" compiler should know how to combine live ranges. If you're using a compiler that doesn't know how to do this then presumably performance is not an important feature for you. – Hot Licks Jul 29 '13 at 22:51
  • @HotLicks That's what I meant when I say reuse it. "Reuse" is not just the simple re-assignment of a value - it's a re-purposing of a symbol name, since this is what may introduce problems to other maintainers. The compiler doesn't care what a variable is used for. – xxbbcc Jul 30 '13 at 03:26
  • @millimoose On the contrary, I think you're looking at a restricted set of languages. Look at languages like Javascript, AS3, PHP, etc. - exactly because these are not very high-performance languages, their interpreters / compilers may skip a number of optimizations and this would be exactly what may lead a programmer to conclude that some memory can be saved. You may be right when it comes to C (I never argued that) but I disagree with your statement in a more general context. – xxbbcc Jul 30 '13 at 03:31
  • @xxbbcc At least *two* Javascript interpreters provably use compiler techniques whose intent is to enable fast register allocation (which should involve live range combining) in a JIT. Seeing as ActionScript is close enough to JavaScript, it's plausible it's just as capable. I submit that my set of languages is restricted to "**any** language with an actual compiler or JIT" because this is such a fundamental technique. This probably excludes straightforward interpreters like Python (and maybe PHP but Zend Engine internals aren't well-known), but there the battle for memory use is lost anyway. – millimoose Jul 30 '13 at 15:23
  • @xxbbcc So, yes, in the very, very general case, languages+runtimes where this matters do exist. Except a) you're not using them, and if you are, then b) you don't care about that sort of memory overhead. And honestly, my objection is mostly about the phrasing of "well-writen optimizing compilers", where I'd say "everything you could call a compiler without stretching the definition of the word". To me it seems like it overstates the likelihood of **any** memory savings occuring in practice. – millimoose Jul 30 '13 at 15:24
8

As with almost everything in programming, it depends on the situation.

If you're reusing the same variable for different purposes, then it makes your code less readable and you shouldn't be doing it. If the purpose is the same (e.g. loop counters), then you can reuse with no problem since this isn't making your code less readable.

Reusing a variable will avoid reserving space in the stack, which results in a faster (you don't waste time reserving space in stack and pushing the value) and less memory consuming (you're not storing it in the stack) program. But this benefits are absolutely negligible in the whole program context, and also relative to architecture, language and compiler. So I would worry more about readability than this tiny benefits.

m0skit0
  • 25,268
  • 11
  • 79
  • 127
6

Bad. For simple types like ints, passed by value, the compiler will be able to figure out when they are unneeded and reuse the space.

For example, I compiled the following C++ code in Visual Studio 2010 using 32-bit Release mode:

for (int i = 0; i < 4; ++i)
{
    printf("%d\n", i);
}

for (int j = 0; j < 4; ++j)
{
    printf("%d\n", j);
}

and got the following assembler output:

; 5    :    for (int i = 0; i < 4; ++i)

    mov edi, DWORD PTR __imp__printf
    xor esi, esi
    npad    6
$LL6@main:

; 6    :    {
; 7    :        printf("%d\n", i);

    push    esi
    push    OFFSET ??_C@_03PMGGPEJJ@?$CFd?6?$AA@
    call    edi
    inc esi
    add esp, 8
    cmp esi, 4
    jl  SHORT $LL6@main

; 8    :    }
; 9    : 
; 10   :    for (int j = 0; j < 4; ++j)

    xor esi, esi
$LL3@main:

; 11   :    {
; 12   :        printf("%d\n", j);

    push    esi
    push    OFFSET ??_C@_03PMGGPEJJ@?$CFd?6?$AA@
    call    edi
    inc esi
    add esp, 8
    cmp esi, 4
    jl  SHORT $LL3@main

; 13   :    }

You can see that the compiler is using the esi register for both i and j.

japreiss
  • 11,111
  • 2
  • 40
  • 77
3
  int x=0;

  //..
  x = atoi(char_var);

  //..
  int x = 0;

You cannot redeclare x in the same scope. If you are not redeclaring it but using it for different purposes, you are free to do this. But it's a bad practice and should be avoided as it decreases code readability. Also you should find meaningful names for your variables for the same reasons.

ouah
  • 142,963
  • 15
  • 272
  • 331
2

You can re-use it but i don't think it will bring a any significant benefit to your programm and it will make your code less readable.

Jackyto
  • 1,569
  • 3
  • 15
  • 33
2

Put it this way - how would you like it if I wrote a big pile of undocumented, complex code in such a way and, then, you get the job of maintaining/enhancing it.

Please do not do such a thing, ever :)

Martin James
  • 24,453
  • 3
  • 36
  • 60
1

In general for any language, if you reuse variable names, and then you decide to refactor part of your code into another method, you end up having to add or edit declarations.

int i;
for(i = 0; i < 10; ++i) {
    printf("%d\t%d\n", i , i * i);
}
for(i = 0; i < 10; ++i) {
    printf("%d\t%d\n", i , i * i * i);
}

Suppose you take the second loop and move it to a print_cubes method. You will not be able to just cut and paste the for loop, as i will have no declaration there. A good IDE might be able to insert the declaration, but it might worry about the side-effects on i in the code you've typed.

In general, compilers can consolidate used variables by what are called graph-coloring algorithms. Consider this variant:

for(int i = 0; i < 10; ++i) {  // BLOCK 1
    printf("%d\t%d\n", i , i * i);
} // END BLOCK 1
for(int j = 0; j < 10; ++j) { // BLOCK 2
    printf("%d\t%d\n", j , j * j * j);
} // END BLOCK 2

The compiler lists the used variables: i, j. It lists the blocks being used: BLOCK 1, BLOCK 2. The parent function is also a block, but i and j are visible only in BLOCK 1 and BLOCK 2. So, it makes a graph of the variables, and connects them only if they are visible in the same block. It then tries to compute the minimum number of colors needed to color each vertex without giving two adjacent vertices the same color, similar to the Haken-Appel Four Color Theorem. Here; only one color is needed.

Eric Jablow
  • 7,874
  • 2
  • 22
  • 29
0

It is better to reuse variables in terms of memory. But be careful you don't need the value in a variable before reusing it. Other than that, you shouldn't use always the variable. It is important to keep a clean and readable code. So I advice you to choose different variable with names depending on the context so that your code don't become confusing.

You should also take a look at dynamic memory allocation in C, which is very useful to manage memory and variables.

https://en.wikipedia.org/wiki/C_dynamic_memory_allocation

Vincent jaouen
  • 157
  • 4
  • An optimizing compiler will typically optimize away extra variables anyway, so reusing variables won't even save memory most of the time. – cdhowie Jul 26 '13 at 14:50
  • Just FYI, local variables are not dynamically allocated. – m0skit0 Jul 26 '13 at 14:55
  • -1: Considering that compilers, whether they're optimising or not, usually work off an IR in [single static assignment form](https://en.wikipedia.org/wiki/Static_single_assignment_form) where every time you assign a value to a variable, a "new" local variable is synthetised, reusing a name should make exactly no difference to the generated code. – millimoose Jul 29 '13 at 12:59
-2

Only drawback is readability of your code.

Reusing variables you are saving memory.

Speed is not affected (unless you have to use more instructions in order to reuse variable).

LS_ᴅᴇᴠ
  • 10,823
  • 1
  • 23
  • 46
  • 3
    Reusing variables will not save any memory if the compiler is good enough -- it is allowed to optimize away redundant variables as long as it can prove that usage does not overlap. – cdhowie Jul 26 '13 at 14:48
  • 2
    Are you actually sure this isn't optimized out? It seems reasonable to me that a compiler could tell `int x` isn't referred to again in a function, and store the subsequent `int y` in that memory. – djechlin Jul 26 '13 at 14:48
  • -1: No you are not saving memory. Read about [static single assignment form](https://en.wikipedia.org/wiki/Static_single_assignment_form) - the compiler IR makes no difference between reassigning to an existing variable and assigning to a new one. What matters is the overlap in lifetime between *versions* of a variable. When optimizing, the compiler will use as much memory as is needed for the maximum overlap. When not optimizing, the compiler will actually use a new memory location for every subexpression - you can see this using the `-G0` flag to gcc. – millimoose Jul 29 '13 at 13:01