3

It seems to be the case with the BCL to use underscores for private local variables. I never use them, but get away like this:

int count = 0;

this.Count++;

public int Count
...

public ClassName ( int count )
{
    this.Count = count;
}

What are your thoughts on this? Are they are problems with my approach?

GEOCHET
  • 21,119
  • 15
  • 74
  • 98
Joan Venge
  • 315,713
  • 212
  • 479
  • 689
  • 2
    You will never get a consensus on instance variable naming conventions. – Adam Robinson Apr 28 '09 at 17:51
  • Very similar to http://stackoverflow.com/questions/450238/to-underscore-or-to-not-to-underscore-that-is-the-question – Neil Williams Apr 28 '09 at 17:54
  • This question is definitely subjective, but I'm not sure about argumentative. the OP is asking for problems with her approach. There are some potential problems, and they're worth exploring. I tend to believe that this question is purely a reputation grab, but it does have its merit. – Michael Meadows Apr 28 '09 at 18:18
  • Yeah how can the problems with my approach be subjective. It would either be true or false. – Joan Venge Apr 28 '09 at 20:03
  • Well that would be subjective, because it still boils down to subjective opinion; there's no objective benefit or drawback. Some people have solid reasons to do it one way or another... based on preference. – Michael Meadows Apr 28 '09 at 20:25
  • 1
    Yeah but I am talking about technical problems, not personal opinions. Like naming collisions, etc, which doesn't happen. – Joan Venge Apr 28 '09 at 21:16

7 Answers7

3

This is basically something you'll have to decide upon yourself, just find or make a style guide and follow it.

Personally, I use _ as a prefix for private fields of the class.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
2

The simple rule we use here is: Private implementation details of a class, including variable names, are completely up to the developer who makes it. Public/protected method names, properties, class names, and so on, are subject to best practice guidelines. Internal types can even be considered to be part of this, since they are not publically visible.

When someone else needs to use your library, it will never have to work with internal or private types, will not see if you used underscores, etc. In other words, this is really up to you....

Just keep in mind that if someone else has to maintain your code later that it should not be too obfuscated...

Jeroen Landheer
  • 9,160
  • 2
  • 36
  • 43
1

It's not required to use the underscore to denote private variables. It's all personal preference. I use them only so I know I'm using the local variable rather than having Intellisense accidentally use my public Property instead.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
1

I use underscores. It helps me keep variable scope in check and reduce the possibility naming collisions.

Chris Brandsma
  • 11,666
  • 5
  • 47
  • 58
1

Underscores make more sense for languages that are not case sensitive (like VB.Net). In languages like C#, it comes down purely to personal preference.

If you have an aversion to putting this. in the front of some ambiguous assignments, then underscores are for you. Without them, you can occasionally accidentally do things like this:

private int that;

public void AssignThat(int that)
{
    that = that;  // assigns to method scope variable, not instance scope
}

FXCop or R# should catch this for you, and I believe you get a compiler warning, but it is possible.

Michael Meadows
  • 27,796
  • 4
  • 47
  • 63
0

IMO, you should never name a private member variable the same as the name of a property, method, or anything else, for that matter. It should be clear which named item you are working with. This will make your code easier to understand and maintain, and will reduce programming errors by yourself, or other developers who need to maintain your code.

Also, if you ever wanted to port the code to VB, that particular naming would not work. Not sure why you would want to switch to VB, but it happens.

Brandon Montgomery
  • 6,924
  • 3
  • 48
  • 71
  • Other than VB port, why do you think it would be unclear? If it's small case, then it's private? You were thinking of something else? – Joan Venge Apr 28 '09 at 17:58
  • 1
    I have seen very large classes with (multiple) screens full of instance variables where it's very hard to maintain because you can't determine the scope of variables. It's a symptom, however, that you should refactor to smaller classes. In small classes with a reasonable amount of private state variables, unprefixed instance variables are quite maintainable and easy to understand. – Michael Meadows Apr 28 '09 at 18:14
  • Thanks Michael, can you please give an example? I don't know how one wouldn't be able to know the scope of any variable by just looking at the name, using my approach? – Joan Venge Apr 28 '09 at 20:04
  • My example can only be anecdotal since I'm talking about classes that are too big to comprehend. Instance variables aren't the only thing that suffer in these classes. Imagine an 30,000 line class. Knowing what variables are available in instance scope in these cases can be aided by using intellisense to give you suggestions when you type "this._" since finding the variables means scrolling through pages of declarations at the top of the file. Like I said, though, that's probably the least of your problems if you have the "God Classes" in your codebase. – Michael Meadows Apr 28 '09 at 20:28
  • I see. Yeah I wouldn't have 30k line classes. – Joan Venge Apr 28 '09 at 21:18
0

There is a practical reason to use a prefix, IntelliSense. ATM it is braindamaged in the way that it does not really distinguish between current instance variables and inherited properties/variables. So using '_' for private variables makes it easier to locate variable within intellisense list and function/variable list in VS code editor. So in a way it is wider-scope hungarian notation.

Pasi Savolainen
  • 2,460
  • 1
  • 22
  • 35