tags:

views:

148

answers:

2

Sometimes it can be confusing reading code in instance members that refers to other instance members of the same class (or a base class):

public void MyMethod()
{
    Where = did + AllTheseWeirdThings(GetDeclared()); // ?
}

Having a coding standard something like "prefix all private/protected members with "_" doesn't help, because instance members can still refer to public members.

It would be much better to read this:

public void MyMethod()
{
    this.Where = this.did + base.AllTheseWeirdThings(this.GetDeclared()); // ?
}

Is there a way to enforce this, either with compiler options, StyleCop, or something similar?

+3  A: 

In C# this and base are optional. The only time you need to use them (in this context) is if there is an ambiguity. There is no compiler switch to change this behaviour.

I'd also suggest not adding the StyleCop rule. It's generally better to only use this and base when you have to, for example in a constructor you might write:

this.foo = foo;

Enforcing usage of the "this" and "base" keywords won't make the code any better quality, or any more readable. If your code is so confusing that you can't figure out where members are defined I'd suggest refactoring it and making your class heirarchy simpler.

Mark Byers
Fields are typically distinguished, as by a leading underbar, just to *avoid* the need for `this.`. So, yes, I agree that this is not a rule we would want.
Steven Sudit
Sometimes using "this" and "base" makes the code worse quality. Using the original example, if it becomes necessary to make base.AllTheseWeirdThings() virtual, you now have to search through your code to remove your calls to base.AllTheseWeirdThings(), or more likely, you forget until something doesn't work. That's actually the reason why I stopped using this/base the way it's being suggested.
Joel Rondeau
@Joel: I'd say it *often* makes things worse.
Steven Sudit
I agree it's better to refactor code that's confusing and make class hierarchies more shallow. However, sometimes it's hard to refactor large legacy codebases without management's blessing. I often have too much other work to do. :)
Colonel Kernel
@Colo: If the code is in need of refactoring but you don't refactor it, then the expected consequence is that development slows down and defect rate increases. In other words, if you're "too busy" to fix things, you will get even busier, and not in any productive way.
Steven Sudit
@Steven: Tell that to my boss and his boss. ;-) Technical debt is called "debt" because sometimes the business wants to carry short-term debt to achieve some long-term goal. It doesn't mean I have to like it, but this is reality.
Colonel Kernel
@Colonel: I'll be glad to, since I'm in a position to tell them the truth without getting fired for it. Technical debt is called "technical" because it's hard for non-technical people to evaluate. As a result, they typically fail to recognize its full extent, and therefore get in over their heads. If you let them do that, of course, you'll get the full blame when the debt slows your development speed to a crawl.
Steven Sudit
+5  A: 

There's no compiler option that enforces your rule.

However, a cursory Google search brings up this StyleCop rule: http://www.thewayithink.co.uk/stylecop/sa1101.htm

ReSharper has a similar option.

Tim Robinson
+1 for finding the StyleCop rule.
Mark Byers
Tbh I found google.com; Google did the rest.
Tim Robinson
But how did you find google.com without using google.com?
yodaj007
@yodaj007: Same way the rest of us did: on SO.
Steven Sudit