Percy’s Random Ramblings

To “this.” or not to “this.” – that is the question Tuesday, 09/06/2011

In my profession there are a lot of ways to accomplish specific tasks. Some of the ways to do things are better in a quantifiable way than others. Then, there are certain things which, while they may be drastically different, have no impact on the end result (efficiency, maintainability, readability, etc.).

There are also people in my profession that cling to the way they do things, to the point of ridiculing those who do it differently. Now, while the ridicule part is inappropriate, I don’t have a problem with someone having a different opinion. However, if you can’t prove that whatever idea/process/standard you’re advocating falls into the first category – quantifiable improvement – then what you are pressing is your opinion, and the one I have is just as good as yours. Further, if I can prove that my opinion actually is an improvement in a quantifiable way, then, realistically, mine is better than yours. At that point, it’s not an ego thing, it’s a provable fact. You don’t have to come to my side of things, but you do have to concede that you’re way is deficient in some way. The same thing goes the other way. If you can prove your way is better than mine in a demonstrable way, then usually I’ll concede and adopt you’re ideas as my own.

Developers get very passionate about code style, and, truth be told, I’ve been known to belligerently uphold those opinions of mine. I’d like to think I’ve mellowed in my maturity, but I have my moments. One of those code style conventions is the use of “this” or “base” to access object properties or call methods of the current or parent object. This actually goes along with using the object name in references to static properties or methods. The prevailing and popular thought on this is to not use either one of these conventions. I believe I can show that actually using these conventions can make your code more readable, if only slightly. If there’s an argument against using these that trumps code readability in this manner, I’d certainly enjoy hearing about it. I’ve actually convinced some people who held the popular opinion that it’s actually better to do things differently.

Just so we’re clear, the idea of increasing code readability is the practice of pushing as much information into the actual writing of code as possible so that ancillary information (usually in the form of comments) becomes unnecessary. You try to write your code in such a way as the meaning of the code and the information you’re attempting to convey leaves as few questions as possible. The idea is to be as precise as possible so that when people come behind you (and if you’re code has any chance of surviving past your own dev cycle, people will) they don’t have to infer or assume anything. Now, where there’s a rule, there’s the use of it in moderation. There’s a swing of the pendulum that goes too far when you have method or property names that start to crack four digits in length. I don’t think what I’m proposing goes that far.

So, here’s my proof. Let’s take a simple, yet extremely common, class called Customer, that has over 200 lines of code in it. I think we can all agree that any main entity in an app will probably have more lines of code than this, but this will suffice for the sake of this discussion. The point is that we deal with classes that are larger than our “viewport” more often then not.

Now, let’s say, you’re coming in after someone to fix a problem with their code, and you see this:

Now, the error you’re getting is that there is a null reference exception at line 166. Let’s take a step further, and say that the “Code before” and “Code After” constitute enough code that you don’t even have the method prototype on the screen (I think the argument works without this, but let’s take it to the extreme). Ok, what’s the scope of “Reference” in this context? Is it static or local? Is it a property of Customer, or is it part of a completely different object called Reference? Where is this property defined? Is it in this method, the Customer class, some base class or in a completely separate class? Should you be checking the constructor to see if it’s set (local scope) or some other entity’s process (static scope)? Now, you can use all kind of IDE features to find out that information, but you have no idea just by looking at the code. There are some questions that you can’t answer by simply reading the code – i.e, the readability of this code is diminished.

Now, what if you saw this, instead -

Then, I could answer those questions simply by reading the code. Reference is a local variable for the object Customer. It’s defined somewhere in the Customer class (given that with partial classes, that might be across multiple files). The same holds true for using “base”, except that you know the property is defined in another class. In this case, the readability of the code is increased over the previous example.

Or, what if you saw this -

Again, you could answer the questions. Reference is a static property of the object Customer. It’s defined somewhere in the Customer class. And, again, the readability of the code is increased over the first example.

Yes, I know you can just hold control, and click on “Reference” to go to it’s definition, or right click and “Go To Definition”. I’m not saying you can’t answer the questions I posed at all without using “this”, “base” or the object for static properties. All I’m saying is that it’s easier to answer those questions if you do use them. So, to me, that makes the code more readable. In my opinion, better code readability is worth the extra few keystrokes you have to use to add this feature in the long run – especially in the Intellisense age of development.

I know that some people can be passionate about these kinds of things. I like using this convention, and I think it makes my code better in a way that I can quantify. So, I’m going to use this every chance I get until someone convinces me otherwise. If you disagree, so be it. I’m not going to hold that against you. Even if I see your code not using it, I won’t change it unless I really need to. The only time I might question you a bit farther on it is if you’re entire rationale is based on “because MS/ReSharper/Visual Studio/my boss/[insert other authority figure here] says so.” Why do they say so? I think that even if some authority on a subject makes a statement, they need to back it up with something or we need to find out the reason behind it – it may be a good one or not. “Trust, but verify”.

So, what do you think? Agree/disagree? If you disagree, why?