Thursday, October 11, 2007

The 'this' keyword - a plea for revival

Give 'this' a chance!

I'm here to make a point for the revival of the use of the keyword 'this' in programming (in the languages where it exists, that is).

But first of all, why revival? Is it dead, extinct, forgotten? I certainly hope not. But I think it's falling in disgrace in the programmer community.

I'm an ActionScript programmer myself and last night I was reading 'Essential ActionScript 3.0', by Colin Mook (which book, by the way, I received from what I believe was the first Romanian Flex Camp - thanks, guys). There was an entire subheading dedicated to the use or omittance of the keyword this (strangely named 'Omitting the this keyword'), and the main idea I got from it was that since the compiler is smart enough to detect member variables even when this is omitted, then why should programmers go through all the trouble writing it?. Their supporting argument was that writing this 'can be laborious and can lead to clutter' and that a this-free code 'improves readability'. To this point I was already pretty annoyed witht their reasoning; next came the only reference to the quasi-positive aspects they see in using this: 'However, some programmers always prefer to use this simply to distinguish instance variables and instance methods from local variables'. Not cool!

This having been said, here are my arguments for the use of this:
  • it's compiler friendly
As Colin explained, when encountering an identifier, the Flash / Flex compiler starts to look for matching variables or functions in this order: parameters passed to the currently executing function; locally declared variables; nested function (function within function); instance variables or methods. This means that when you omit the this keyword, the processor goes through 3 redundant cycles until it finds the instance variable or function which you referenced. It's that simple. This is pretty similar to simplifying constants as much as possible (such as writing 2.5 in the source code instead of calculating 5 /2), because when you take the time to type this, you are actually skipping three useless checks, thereby improving the speed of your application, even if by a meager margin.
  • using this is [usually] more readable than not
I can imagine that this is probably a pretty bold statement, but I think it's true, for the following reason: when you read a piece of code yourself, whether it's yours or not, and stumble upon an identifier, your brain does pretty much the same thing the compiler does: checks whether the identifier is a function or variable (you understand that from context), then looks to find whether it's local (passed as an argument or defined in the function - it's important to note that unless the identifier is familiar to you, you will actually move your eyes above the current line, scanning for a local instance declaration, until you find the function signature and check that too - which, needless to say, is time consuming) or whether it's an instance member (in which case you usually hit Ctrl+Home and check to see if the identifier is a member of the current class). Yes, this can be pretty quick for small classes and functions, but when an instance function spans for 20 or so lines and the class has many instance variables (for me this is not a rare occasion) and at a given point you see the line 'index = oldIndex;' for example, you have to start digging for scope and parenthood. Who is index and who is oldIndex, is any of them an instance variable and so on. Had the line been written 'this.index = oldIndex' (and had the convention been applied that all identifiers which don't have a 'this.' attached to them are local), you would have just moved on, as both variables' scope would have been obvious.

Ok, and what about the supposition that writing this all the time 'can be laborious and can lead to clutter'? What's interesting is that there is a certain similarity between this and public - they're both self-understood, aren't they? Yet, as much as I know, almost no-one omits public. Why might that be? Why would people go through the trouble of writing something which is self-understood? I think it's that because it saves you a brain cycle - you don't have to go through thinking that 'if the scope identifier is missing, then it must be public, since that's the default'. And my contention is that the same applies for this. It speeds up reading and clearly specifies parenthood and scope. As for clutter, I think it's quite a trivial argument - there are 5 extra characters. Indeed, when using many instance variables on the same line it might lenghten it to some extent, but I think - and this is actually my overall contetion - that the benefits far outweigh the costs of using the keyword this in your code.

What do you guys say about this? I'd love to hear about your coding practices.

No comments: