views:

307

answers:

5

We were having the (never ending) underscore prefix versus no underscore prefix debate on member variables and someone mentioned that is you use "this." instead of "-", your code will be slower due to the "." in "this.". Is this true and can anyone quantify this?

+27  A: 

No, that makes no sense at all. Just look at the IL, and kick that developer in the ass.

Also FWIW, I like the underscore in member variables.

TheSoftwareJedi
maaaan... underscores?? :p I've never liked underscores period.. since long before I even knew what computer programming was!
DeadHead
I agree except for underscores. I HATE them. I think they make it harder to read (though intellisense can be easier to navigate if you're not using this.)
Jeff Yates
The underscore prefix is wonderful. I find it makes it easy to differentiate between locals and members.
TheSoftwareJedi
I agree with underscores. All my class level private members have underscores. It brings the variables to the top of intellisense list and it separates them from variables the local method level variables.
Chuck Conway
If your editor can't color locals different from members, you need a new editor. Any human convention is fallible and a stupid compensation for inadequate tools.
Bill K
http://stackoverflow.com/questions/717504/what-is-the-best-practice-for-naming-private-and-static-private-methods-in-c
bendewey
Why would you not use underscores? I love them, even when you use the built in refactoring in VS for encapsulation it automatically creates a property for your member variable and removes the underscore and pascal cases the property.
Alexander Kahoun
@Alexander: You wouldn't use them if (like me) they slow down the way you read code. I believe different people read code differently - I subvocalize it, and underscores get in the way. I'd also say that if you can't tell the difference between local variables and instance variables easily, your methods are probably too long...
Jon Skeet
Underscores are wonderful on private members, couldn't live without them :)
Kenny Eliasson
Jon_Skeet_reads_this_very_slow!
TheSoftwareJedi
I only use underscores for class-scoped fields. Which I only ever access through Properties, like any good programmer should.
Will
Bill K, good thing you're not colorblind or work for the government. It's illegal to use a differentiation based solely on color - a violation of the ADA (American's with Disabilities Act)
Stephanie Page
And agreed that if you're relying on a human to do it right, that's a mistake... There are tools that will add underscores for you.
Stephanie Page
+5  A: 

There doesn't seem to be difference when using the this keywords. If you have the following code:

class Class3
{
    private long id;

    public void DoWork()
    {
        id = 1;
        this.id = 2;
    }
}

When you run it through reflector you will see the following output:

internal class Class3
{
    // Fields
    private long id;

    // Methods
    public void DoWork()
    {
        this.id = 1L;
        this.id = 2L;
    }
}
bendewey
+5  A: 

Seems to me that "this." is a disambiguator at compile time. It tells the compiler the scope of the variable. It may be unnecessary, since the compiler will need to figure out scope in any case. But I can't imagine there is any performance downside, perhaps even a microscopic upside as you are "hinting".

Once the code is compiled (ie, at runtime), I imagine "this." is utterly irrelevant.

So it's a style choice. Some people prefer terseness. I like "this." because it adds clarity, when used correctly. It tells other developers where a function or property lives. I use it for any public method or property. I don't usually use it with private members.

Juval Lowy has a very nice C# style guide here: http://www.idesign.net/

Matt Sherman
A: 

Who needs underscores when you got camelCasing? Also I got a say that what you doing sounds like a crazy idea.

dr. evil
I use camelCasing for local variables, and leading underscores for fields
Thomas Levesque
+1  A: 

Variables represent locations in memory. When compiled a 100character variable and a one letter variable are both converted into numbers. In the same way special characters are translated and wont make any difference on the speed.

Marcom
Actually that's not completely true... the variable names must kept somewhere in the compiled assembly, since disassemblers like Reflector are able to show them... But anyway, it has no impact on how the code is executed...
Thomas Levesque
but if I am not mistaken to do that you need the pdb files. My point is that at a low level you'll have tokens that only the compiler will understand irrelevant to the size of the original variable name.
Marcom