In an if statement, what are an “if clause” and a “then clause”

OO, according to Alan Kay is all about message passing, and that's it. You will see that qualities such as polymorphism and encapsulation are actually derived from message passing.

Now that stance is in fact very extreme, because it basically means that only Smalltalk and languages alike would qualify.

I think you can define OO as building your system on entities, that fully encapsulate their state, and that are rendered exchangeable due to their inherent polymorphous qualities. One could thus argue a purely OO language ensures these two core qualities are always met. What renders OO languages "impure" would be mechanisms that allow the creation of constructs that do not meet these criteria, such as the possibilities to:

• declare public fields
• declare variables that can only hold instances of a specific class and its subclasses (i.e. variables should be typed against interfaces, which is what the biological objects communicate through in Kay's anology), which is rendered even narrower if the class in question is final, as that leaves even less room for polymorphism
• declare primitives

Then again, IMHO language purity is more a weakness than a strength. OO is not a silver bullet. No single paradigm is.

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.