Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Sometimes I run into a situation where I need to equate two new variables with an old one. Which of the following (if any) is a good practice (w.r.t. code readability or any other factor), under what conditions?

a=b;
c=b;

or

a=b;
c=a;

Note, a,b and c are just the names chosen in this example.

share|improve this question
    
Which shows the intent? Are a and c both to be equal to b? or is c supposed to be equal to a? –  MichaelT Jun 10 '13 at 3:54
1  
@MichaelT Sorry, I'm not sure what you mean by intent. Underlying values need to be equal. –  user13107 Jun 10 '13 at 4:23
    
"a and c are equal to b" vs "a gets the value of b, and c is a loop index that is initialized to a." These are different statements that have different implications on the code that is written. –  MichaelT Jun 10 '13 at 23:23
add comment

3 Answers

up vote 5 down vote accepted

Humans are Parsers Too! Encourage Maximum Readability!

Given your 2 choices, I'd favor the first one:

a = b;
c = b;

It's easier to visually parse and to figure out that both a and c now have the same value as b. Or at least you quickly see that 2 separate things get the same value.

In the second example, none of this is immediately obvious.

Discourage Ambiguity

I'd also discourage one-liners (a = b = c;) for similar reasons, and because they hide multiple expressions in a single statement. This facilitates the introduction of fly-by errors* and leads to developing a (bad) habit of cramming too much in too little space for a false sense of expressiveness.


* For instance, I've often come across things like:

  • a = b = b; (when obviously a c was intended somewhere),
  • and then quickly you'll see things like if (a == (b = c)) {}... and now you're one typo away from if (a = (b = c)) and then you've got absolutely no clue what the intended behavior was. Ah, and use descriptive variable names, obviously.
share|improve this answer
    
I guess it is a moot question as to when code stops being terse and starts becoming unreadable. Ternary operators seem to be a particular bone of contention in our office e.g. result = a > b ? x : y; –  Robbie Dee Jun 10 '13 at 10:53
    
@RobbieDee: ternaries are fine as long as you don't abuse them: you just use them to return an expression's result based on a condition (but not to branch entire sections of code), and you don't nest them unreasonably just for the sake of saving some lines (though formatted correctly, thay may be decently readable, it's likely you can re-design your logic differently). –  haylem Jun 10 '13 at 11:03
add comment

If the language allows for this syntax (and most do), I'd highly prefer this:

a = c = b;
share|improve this answer
add comment

I'd be inclined to agree with deceze. Yes, this example is clear(ish):

a = b; 
c = b;

But introduce more variables and it just becomes horrible:

a = z;

b = z;

c = z;

.

.

.

w = z;

x = z;

y = z;

At which point would you draw the line and go for the single assignment statement? 3 variables? 4? 5?

Setting some arbitrary limit would seem to be daft (and in contravention of the Zero One Infinity Rule).

share|improve this answer
1  
one would hope that as you introduce more variables you eventually use some sort of collection instead –  jk. Jun 10 '13 at 10:07
    
@Robbie: I think that if you start to introduce variables this way, your problem lies somewhere else... Either in your overall design, or in the fact that you don't separate that into smaller chunks and functions anyways. –  haylem Jun 10 '13 at 10:29
    
Yes, the extreme example was designed to demonstrate that if it doesn't scale for more elements, the approach shouldn't be used at all - hence why I upvoted @jk. –  Robbie Dee Jun 10 '13 at 10:37
    
@RobbieDee: using lots of if() {} statements doesn't scale either. Doesn't mean you should avoid them at all costs. –  haylem Jun 10 '13 at 11:05
    
We're in danger of speculating about designs on imaginary code so I'm going to side-step that one as off-topic... :) –  Robbie Dee Jun 10 '13 at 11:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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