Thread: this pointer?

Originally Posted by brewbuck

I still don't grok the argument. It sounds like you're saying that coding standards are dangerous because people might forget to use them. Okay... People also forget to update comments, they rely on undocumented and fragile behavior, they don't validate input, they don't check array bounds before accessing, etc. It seems like the safest practice is to just not write any code at all because somebody might make a mistake.

Suppose there is a coding standard in place that says "Every variable must be initialized at the point of declaration." I suppose you take issue with this as well, because somebody may forget to adhere? And the answer is to deliberately not initialize variables?

I said I don't like the fact that style-related "standards" dominate every standards doc I've ever seen, as opposed to those that encourage/enforce good programming practices. We *should* be looking for things like programming errors instead of wasting time dotting i's and crossing t's.

Originally Posted by medievalelks

I said I don't like the fact that style-related "standards" dominate every standards doc I've ever seen, as opposed to those that encourage/enforce good programming practices. We *should* be looking for things like programming errors instead of wasting time dotting i's and crossing t's.

The coding standards I had long ago were over 95% coding standards and only a few style guidelines such as always use tabs to indent (and set the IDE tab size to 4), use m_ for member variables, and start public functions with capital letters and private/protecteds with small letters.

I find the "this" pointer useful when working with arrays of class objects

Code:

class Example{
  private:
    int value;
  public:
    void dispValue(void);
};

int main()
{

  Example stuff[10];
  int i;

  for (i = 0; i < 10; ++i)
    stuff[i].dispValue();
}

void Example::dispValue(void)
{
  cout << this->value;
}

this-> is not necessary at all in this example.

Originally Posted by medievalelks

I said I don't like the fact that style-related "standards" dominate every standards doc I've ever seen, as opposed to those that encourage/enforce good programming practices. We *should* be looking for things like programming errors instead of wasting time dotting i's and crossing t's.

I can agree with that.

The standards document at my workplace specifically indicates NOT to use Hungarian notation, and gives some very good justifications for that (mostly in regard to its uselessness at preventing any real kind of problem). I've never been a fan of it, and would never use it myself unless forced. But an "m_" sort of prefix, in my mind, is not Hungarian notation but something different.

I used to use Hungarian notation all the time when I started programming, but now I don't care. I might use a p prefix to indicate a pointer, but that's about it.

I wonder how much HN-infested code has changed when char * variables where changed to std::string and vice versa. And how much was not changed.