9

I don't use prefix while naming internal variables of a class (I know some do but I am not starting "why do you..." debate). I just prefer it that way. The problem is that sometimes same parameters are passed in contructor and I end up being confused how to name them. For example:

public class SampleClass
{
    private int classId;
    private string className;

    public SampleClass (int XclassIdX, string XclassNameX) {
        classId = XclassIdX;
        className = XclassNameX;
    }
}

How to name XclassIdX and XclassNameX?

One thing that can probably be done is:

public class SampleClass
{
    private int classId;
    private string className;

    public SampleClass (int classId, string className) {
        this.classId = classId;
        this.className = className;
    }
}

Just not sure whether this is a good idea or there are other more elgant ways?

Hemant
  • 19,486
  • 24
  • 91
  • 127
  • 3
    NOT a duplicate: other other question (http://stackoverflow.com/questions/450866) is about C++, this question is about C#. – Richard Mar 20 '09 at 13:01
  • 1
    Not quite a duplicate, since standards specifying underscore usage may be different for different languages. On the other hand, the idea applies to more than one language, so these questions could be combined, and individual answers could make recommendations for specific languages. – Triynko Jun 13 '09 at 17:00

8 Answers8

19

I think the solution you're describing, where the constructor parameters are identically named and you prefix the class members with this, is just fine. It's clear, it's concise, and there is no confusion about what you meant.

John Feminella
  • 303,634
  • 46
  • 339
  • 357
5

I simply use the this approach; then all my variables and fields reflect their intent. Don't do the X thing - that is just ugly ;-p

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
3

I cases like this, I don't think any one way is better than any other. But for the sake of other people who might need to maintain your code (and yourself for that matter) I'd say just pick one way of doing it and be consistent about it.

Eric Petroelje
  • 59,820
  • 9
  • 127
  • 177
2

Short answer:

Prefix members and parameters with "m_" and "p_", or "s_" if member is static.

Don't decorate properties or locals, and when you feel you must name them the same (ignoring case), resolve the conflict by prefixing properties with "this.".

Explanation:

Consider that there are at least FOUR(4) different categories of readable/assignable names that need distinguishing: Local variables, Member variables (instance and static), Properties, and method Parameters. All four categories may appear in a single code block, and therefore they each need clear distinguishing characteristics.

A meaningful prefix can simultaneously distinguish variables and reveal their scope such as m_(member), s_(static), p_(parameter), leaving public properties and local variables to remain simple without prefixes and without worrying about case sensitivity. If for some reason you must name a local the same as a property without regard to case, then simply prefix the property with "this."

Naming conflicts between Local variables and Parameters don't occur, because they cannot be named the same thing (compiler will catch the duplicate definition). The same goes for Member variables and Properties. Parameters and members prefixed with "p_" and "m_" respectively will not conflict, and conflicts between non-prefixed locals and properties can be resolved by adding "this." to the properties.

The alternatives to my suggestions are not pretty: use case sensitivity (bad idea, as not all CLR languages are case sensitive), use underscores by themselves (also bad, as it may collide with standards and doesn't tell you a damn thing), or use different names altogether (can be time consuming, difficult, and appear arbitrary).

Triynko
  • 18,766
  • 21
  • 107
  • 173
0

Why not just add an underscore or single letter prefix for your private member variables. If you don't like that idea, what you've done in your second code block is ok.

Matthew Dresser
  • 11,273
  • 11
  • 76
  • 120
0

Putting X on your parameters like that is bad. The constructor is part of the public interface of your class and it will only confuse the users of your class. Some like to prefix the member variables with underscores which is much better as it is only visible to the implementor of your class. Otherwise using this as in your second example will suffice.

Jakob Christensen
  • 14,826
  • 2
  • 51
  • 81
0

m_foo for private members
Foo for public property
foo for parameters and local variables.

I prefer to distinguish the block scope from the extended scope members, that's why I stick with the prefix.

peterchen
  • 40,917
  • 20
  • 104
  • 186
0

You need to separate them in some way. Using 'this.' is a weak form of hungarian notation so you might as well bite the bullet and use underscores or 'm_' .

I also feel 'this.' is actually worse because in extreme cases (i.e. large methods) it is possible the 'this.' will be left off and the wrong variable will be referenced. I know large methods are bad but they do occur naturally in real business applications with developers of varied skill. Using a prefix for private fields will prevent that scenario.

It is tempting to argue that the underscore may be forgotten in the same way as 'this.' would. But that is incorrect because the underscore changes the name of the variable, so the only place it could possibly be forgotten is at the definition, not at it's usage within the file. Whereas with the 'this.' prefix there is no compiler error if you forget it during usage.

Whatever you choose, there's no avoiding hungarian in this situation whether you use 'this.' or underscore. It's not so bad anyway, we are forced by convention to use hungarian for interface names, control names and probably other places I can't think of right now.

LegendLength
  • 473
  • 3
  • 11