C++ – IF statement with OR logical operator

The reason you hear about conditional "clauses" is because English has clauses. When you hear about conditional clauses in programming, what the person is speaking about is "that which embodies the condition."

So the if clause is

if condition then
    statement_1;

because that's the part that pertains to the if.

The else clause is

else
    statement_2;

because that's the part that pertains to the else.

Who 'owns' the parameter passed in?

Consider the situation where the value of color gets modified by the function and its passed in by reference. This may not always be something that you can control (pass by value vs pass by reference).

#include <iostream>
using namespace std;

void doFoo(int& arg) {
    arg++;
}

int main(void) {
    int foo = 42;
    doFoo(foo);
    cout << foo;
    return 0;
}

https://ideone.com/RioRXb

This code prints out 43. The function doFoo got the argument by reference and modified it. This may be what its supposed to do, and there are certainly times to be aware of it. But, if the function doesn't 'own' the argument when it comes in, such a side effect can be quite bad.

This concept of ownership is a real one and has implications in places. In pre-arc Objective C, one would actually call retain and release on things if you wanted to 'own' them. The alternative, you could make a copy of it (not what you're addressing) and own that copy.

Often, the best practice is to consider that the arguments passed in are immutable final things that you shouldn't touch. Reassigning parameters is often seen as a questionable practice - even if the thing can't change. The specifics of if it can change from language to language, or even silently within a language (the perceived difference in passing an Object and an int in Java).

Changing a thing

Setting aside the parameter being modified, code like this sets up the possibility/likelihood of becoming unmaintainable over time.

Modifying the condition for the if (or index in a for loop), in a series of if statements (yes, you've got an else in there) can lead to code where you depend on a value changing state in a previous if, that doesn't (and it has a different state).

This starts getting into rather contrived examples trying to demonstrate it in a short bit of code. Often this comes about with larger blocks of code where you think that nothing later down uses it, so its safe to modify... and then someone comes in, looks at the assignments, looks at the hundred lines of code (you'll find this in code you maintain that "someone else wrote" all the time), skim to where you need to make the change... make the change, and find out that the thing you have here now, isn't the thing that was at the top of the block.

The example code just... its got a whiff of a code smell that has the scent of Same Name Different Meaning - the identical identifiers which would be addressed by Split Temporary Variable. That this isn't a temporary variable is also problematic.