Eric Gunnerson's C# Compendium

I've never personally understood the prefix rationale in C++ and C# as far as "where did it come from" go.. Just use "this->" or "this." respectively if you can't deal without.

Personally, I use _foo for private stuff in python (that's the python convention), fooBar in C# (like all vars), and foo_ in C++ (_foo is reserved, and foo_ is the boost convention for private members).

I'm torn between using _foo and using foo, though I'm tending toward the latter lately.

As regards 'this', I use it because it carries semantic meaning that the language dictates, rather than meaning that is lost when you cross the hallway.

I'd be interested in seeing what a language would look like if it had a specific notation for private fields or local variables, which didn't conflict with public members.  Then this argument would be moot. :)

Mike Dunn - Because m_ is in the variable name, this. or this-> is in the language and carries semantic meaning, like kfarmer mentions.

Furthermore it allows you to omit it where it's clear without clarifying scope of the var.

Personally, I like python convention with 'self' and '_foo'.

I go back and forth. Some days are "m_" days and others are not. I think it relates to how much database work I'm doing that day and whether I'm use to typeing the underscore. But at the end of the day, if I can read it and I can reasonably conclude that others can read it and it compiles, I'm good.

You don't happen to suffer from long methods and/or long classes, do you?

In C++ there is a rational for a prefix like (like "m_").  In the initializer list you cannot use "this" for scope resolution.  So, to avoid having parameter name collisions with fields "m_" is used to delineate fields.

C# was designed to not need the prefix.

Peter - Except, there's no collision: Foo(int bar, int x) : bar(bar) { this->x = x; } works perfectly fine.

RE: CLS compliance.  Only if the fields are public; which is a no-no...

Peter - Sure, it's not the most readable, but for an init list I honestly don't care; There's no ambiguity present.

As for compilers, I've used it with MSVC/GCC/Intel without issue for many years.

The '_' prefix has the advantage that intellisense lists all your private fields at before all other members, at the top of the list.

I'm the only person I've met who likes to use both the '_' prefix *and* the 'this.' qualifier on field references.  

This is because, after working on C# IntelliSense for a few years, I am very comfortable using its features.  'this._' is a powerful way of directing IntelliSense to get you what you want.

Just use "ClassName." on static members...

jaybaz_MS,

You're not alone in this world ;-). I both use _ prefix for private member variables and the this. qualifier on references to those fields.

I think the _ prefix is the shortest most readable prefix for private fields that share the same name as the properties they most of the time belong too and 'this.' makes my code more readable by separating local from member variables.

The periodic identifier naming/prefixing/Hungarian-notation religions discussion reared its head recently

this.variable <-- class scope variable

ClassName.variable <-- class scope static variable

variable <-- local scope variable

Your methods should never be longer than a few lines, so examining whether "variable" is a parameter to the method or one you declared locally should not be a problem.

Using "this." and "ClassName" makes the scope of the variable explicit and EVERY developer out there that knows what these mean (do you want them working for you if they don't?) can understand the coding standard without having to read a document.

What is even more important is that this can also be applied to methods consistently.

this.MethodName() <-- class scope method

ClassName.MethodName() <-- static scope method

We use "my" for this. It's the same length as "m_", it's a real word, and it expresses the ownership relationship between the class and the member variable.

We didn't want to use Hungarian when we moved to C# but we came to the conclusion that there's a difference between including type information (not a good idea any more) and what could be described as variable meta-information - like it how it is meant to be stored or used.

For us, indicating whether a variable is a member variable fell into the realm of useful meta-information.

We wound up picking a short list of approved lower-case prefixes for variables. Our aims were to give some useful meta-information, to comply with the camel-case recommendation of the Framework Design Guidelines and FxCop, and to use meaningful words to do it. Oh, and just in case it wasn't clearly implied by that last point, we wanted to completely eliminate underscores! At least one member of the team went into convulsions at the very sight of an underscore ;-)

Here's our list of prefixes:

const: a constant

my: a member variable of a class

a (or an): a local variable used to access members of a collection

loop: a local variable that will be used to control a loop

the: any other local variable

in: a parameter that is only passed in to the method

out: a parameter that will hold data inserted by the method

io: a parameter that performs both "in" and "out" roles

In practice, I'm not sure if we've ever used "out" or "io", but the others are used consistently in our code and do seem to prove useful.

class Foo

{

  private int bar;

  public int Bar { ... }

}

1.  As I've said before, basing naming decisions on the amount of typing you'll have to do is ALWAYS wrong.  Intellisense and code snippets, if required, can always reduce typing to at least as little as you could reduce the name to, sometimes to even less.

2.  Basing a naming convention on the need to know where a variable is declared is just as wrong.

2a.  Usage should usually make it obvious.

2b.  When it's not obvious, you've got an indication of a much bigger code smell that needs corrected now.  The most likely problem is that you have a function that's too long and needs refactored.  Effort spent doing this will pay off much more than any effort made in using prefixes to distinguish where a variable is declared.

3.  When there's a collision between a local and a member, "this." and "Class." are more meaningful ways to distinguish.  I prefer to reserve this for when there are collisions, but if you're in the "less typing/use intellisense" crowd, I have no problems with using this more liberally (by the way, a code snippet for "this." can reduce typing to 2 characters, the same as your "m_" prefix, but with the added benefit of calling up intellisense).

4.  CLS compliance should never be an issue here.  Public/Protected fields and properties are always Pascal.  Private fields are always Camel.  No combination of properties and fields should result in a collision or CLS compliance issue.

5.  Code reads better with out prefixes.

I like to use mMyVariableName, _ is no good because then your classes aren't CLS compliant if you use a protected variable. m_ is too much to type IMO.

I use the '_variable' for all Global variables and just 'variable' when in methods. The '_' allows me to quickly see if the variable is global!

Actually, the IDE should show public, private, and local variables in separate fonts. Const or static identifiers would be distinctive as well, and globals, in languages that have them, would be displayed using the blink tag.

How many naming conventions were violated here?

http://msdn2.microsoft.com/1h3cat6t.aspx

I like Joseph Newcomer's comments on the topic of "m_".

He describes the use of "m_" merely as a compulsion.

And "...if using "m_" was the only correct and sensible way to designate member variables, don't you think Bjarne Stroustrup would have designed the language that way and no other?"

I fully agree with Paulo and Peter because the prefix normally shows that the code is not really readable enough, and so the prefix appears to save the day.

I normally use in private fields the name using camelCasing, and when i call it normally i use this.<fieldname>.

As for the m_ or _, i normally don't use none of them, but the _ doesn't shock me because it has the nice this of putting all that fields first in the intellicense, but i don't like the m_, because i don't know why m_ and and not v_, i_ or anything else in the alphabet. If this m_ is really the a naming convension then i agree with Paulo, the next stop will be Hungarian notation again, and honestly i hate it.