Oh, one more thing

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

Yay - _another_ verification blog

That's it - I've finally caved in and got myself a public blog.  I'm not sure if it was because of the success of the Blogging Birds of a Feather session at DAC, the fact that a few of my colleagues (JL, Tommy & Gordon) are having fun with their blogs, or the fact that my flight home from DAC isn't for another 11 hours, and I'm at a loose end.

The hardest part so far has been choosing a name for this thing.  I'm sure content will be harder, but one step at a time, and all that.  I'll reckoned that I'll probably end up using this blog to write down the things I wish I had said during discussions [1], so "Oh, one more thing" seemed apt.

Have fun

[1] A few years back I had enough things to say after a particularly annoying conversation was over that I ended up writing a book. I'm hoping that the blog will prevent that kind of madness from happening again