Dissing this

Damn damn damn damn.  I promised myself that I wouldn't get involved in any more conversations about coding styles - ever, and then Janick has to go and write "Do they diss this “this”?"  Use of "this." is a pet hate of mine as it's nothing but a source of annoying bugs.  Janick has done an excellent job of explaining what "this." is for, and why you might want to use it, so I'm just going to be lazy and focus on why you might not want to use it. 

The "this." keyword has only one purpose, and that's to let you differentiate between class member variables and local variables (local as in scope, not local as in access rights).  I hope Janick doesn't mind me stealing part of his example here:

class packet;
   bit [47:0] da;

   function new(bit [47:0] da);
      this.da = da;
   endfunction
endclass

What we have here is a member variable called da (global scope within the class), and a parameter called da (local scope to the new() method).  When you're in new(), they're both visible and now you have to do something special to untangle them.  You could compulsively use "this" to solve the problem I suppose, but I'd suggest that avoiding the problem in the first place might be an all round better solution.

The problem with "this" is that if you forget to use it, or if it gets edited out of the code, then your code will continue to compile, but will now have a subtle error where the incorrect variable is used.  Here's what Gordon Allan, a colleague of mine (and I should add, one of the best coders I've ever met), said about this on his internal blog a while back:

"After much heated debate (religious wars even) I've decided to stop using "this." after chasing down a simple typo-induced bug for an hour, that was masked by "this." usage. Hungarian (or any similar) notation would have avoided it, and that wasted time is a good enough reason for me to switch. To what, though?

In our earlier debates we talked about 'this.' or 'me.' qualifiers being nothing more than unnecessary decoration in most cases. (I was one of those who sometimes liked that decoration, especially as it stood out nicely in my Xemacs window).

We mentioned that the only 'justifiable' time to use 'this.' was in an accessor method which took parameters named the same as the properties. But I now assert that this is dangerous and should not be used to justify 'this.'. For example:

    function void setFoo( int channel );
       ...   ...
       this.chan = chan;
       ...   ...
    endfunction

Can you spot the mistake above? I had one of those. I mis-spelt the parameter name in the method header, and so my 'this.chan = chan' line compiled OK with both lvalue and rvalue referring to the same thing and never involving the parameter. D'oh! A hungarian naming convention would look like:

    function void setFoo( int channel );
       m_chan = chan;
    endfunction

Which would of course fail to compile, alerting me to the typo."

Now, there's a whole new holy war here about what to use instead of "this".  Perhaps we should put "m_" in front of a class member variable because a member variable is "special". It's different from the other ones lying around you. It's global (to the class), so writing to it has side effects elsewhere in the code, and as a result it should be treated with respect. "m_" marks it as special. So does "__" in C. Incorporating "usage warnings" into variables isn't new. Consider them like the yellow bands on a wasp. Maybe not beautiful, but damn useful.

However, you can validly argue that this pollutes the public interface (which will be the topic of another blog soon), so it would be better to use "p_" for a method parameter or "l_" for something local to the method, or even (god forbid), use a different name.  Or as Gordon finished up:

"So I think I'm going back to my native Java/C# coding styles: PascalCase for names of public things (like classes, properties, methods), and camelCase for names of private things (like local variables, or parameters). That's the only distinction I need to make, so long as I name methods as verbs (and call them after what they do) and classes and properties as nouns (and call them after what they are)."

What you use is entirely up to you.  All I can say is that I've seem "this" do far more harm than good, and while my other suggestions might hurt the aesthetics of beautiful code, they help prevent bugs. As Joel said, "I can live with the shame if it makes me more productive". I have enough stupid bugs as it is without introducing another source in the name of "art".

Cheers
David

Comments

[Janick Bergeron]

Excellent article too! But capitalization to differentiate identifiers? Now *that* is my pet hate :-)

Using a prefix for data members is a good idea when they are private as they do not otherwise affect the user interface of the class (and typical OO guidelines require that all data members be private). However, because of the need to constrain data members in SystemVerilog, the random ones must remain public... and I find that prefix rather annoying.

But reguardless of how you decide to refer to data members, the most important aspect is to be consistent!

Cheers!

[David Robinson]

Hi Janick,
capitalisation isn't my choice either. I'm a fan of "m_" except when the member variable is public. In that case, I try and go for different names completely, or just do something like "p_" for method "parameters" - they tend to be short lived (once they are assigned to the member variable, I'll use that).

It was easier in C++ where you could make all member variables private.

Cheers
David