Normalize constructor parameter names

[hollasch]

In order to avoid confusion between constructor parameter names and member variables, we either used alternate names for the parameters or prefixed the parameter names with an underscore. For example:

class foo {
  public:
    foo(int _i, bool semaphore, short bar) : i(_i), flag(semaphore)
    {
        baz = bar;
    }
   private:
     int i;
     bool flag;
     short baz;
};

However, this is unnecessary. Constructor initializer lists are unambiguous, as the assigned item always refers to the class member, and the assigned value is always from the parameter (unless prefixed with "this->").

Inside the constructor body, parameter names override member variables, and "this->" can be used to indicate the class member in the case of name collision.

Thus, the above code can be rewritten as this:

class foo {
  public:
    foo(int i, bool flag, short baz) : i(i), flag(flag)
    {
        this->baz = baz;
    }
   private:
     int i;
     bool flag;
     short baz;
};

I've taken advantage of this to clarify names used in constructors throughout the codebase. Mostly for constructor parameter names, sometimes for member variable names.

[rupsis]

1 Subjective opinion. Otherwise the changes make sense, and go a long way to unify the code.

[hollasch]

The problem is that col more typically refers to a column. And yes, c often refers to a char. color is out because it's a type name. (Personally, I prefer leading capitals on my type names, but that's not the convention here.

"color" actually isn't a great name, because it makes the common mistake of naming something after its kind/type, instead of what it is specifically. I'll revisit.