I've just started using ReSharper (for C#) and I kind of like its code smells finder, it shows me some things about my writing that I meant to fix a long time ago (mainly variable naming conventions).

It caused me to reconsider some of my naming conventions for methods and instance variables. ReSharper suggests that instance variable be lower camel case and begin with an underscore. For a while I meant to make all my local variables lower camel case but is the underscore necessary? Do you find it comfortable? I don't like this convention but I also haven't tried it yet, what is you opinion of it?

The second thing it prompted me to re-evaluate is my naming conventions for GUI event handlers. I usually use the VS standard of ControlName_Action and my controls usually use hungarian notation (as a suffix, to help clarify in code what is visible to the user and what isn't when dealing with similarly named variable) so I end up with OK_btn_Click(), what is your opinion of that? Should I succumb to the ReSharper convention or there are other equally valid options?

8 Answers 8


You can modify ReSharper to use whichever naming convention scheme you use. It's quite flexible, including customising event handlers, fields, properties, methods with various accessibility levels etc.

Don't let the tool define your standards - use it to enforce your own.

Update: Having said that, at work we use mainly lower camel case for most private things - variables, fields, and arguments. Upper camel case for method names, constants, and properties. Event handlers are named based on the action they represent, rather than something specific to the control - eg HandleCustomerContinue rather than HandleContinueButtonClick. I tried the ReSharper default scheme for a while and actually don't mind it, I'm really not fussed either way.

  • Of course, I really like how it helps me keep my local variables in check but I'm curious as to other people's standards, especially when it comes to event handlers.
    – Ziv
    Commented May 22, 2011 at 10:59
  • Fair enough, I've edited to give some more personal experience detail.
    – mjhilton
    Commented May 22, 2011 at 11:14
  • 11
    +1 for "Don't let the tool define your standards"
    – techie007
    Commented May 22, 2011 at 19:12
  • "Don't let the tool define your standards" has just become one of my favorite programming quotes of all time.
    – seggy
    Commented Mar 23, 2012 at 13:09

With respect to

but is the underscore necessary? do you find it comfortable?

One thing I like a lot about using the underscore, is that it dramatically reduces the use of "this".


public void Invoke(int size) {
    _size = size;

without the underscore, you would have to write:

public void Invoke(int size) {
    this.size = size;

which potentially introduces the subtle error of:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 

In addition, code completion is cleaner because by just tying the underscore you get a list of only the private fields, whereas with "this" you get a list of everything.

With respect to

usually use Hungarian notation

the Framework Design Guidelines: Conventions, Idoms, and Patterns for Reusable .NET libraries says:

DO NOT use Hungarian notation

Leaving little room for ambiguity : )

  • Strictly speaking, if you follow the Framework Design Guidelines, it states that variables that are passed to public methods should be in capitals too, in addition to the method names :) Commented May 22, 2011 at 12:20
  • pzycoman ... can you please point me to where it states that. A quick look and I couldn't find any reference to using capitals in variables that are passed to public methods. But for example, on P 118 of the second edition, there is an example of where public methods are not using capitals but lower case. "public void Write(uint value);" Commented May 22, 2011 at 12:26
  • 11
    In the case of name clashes I would say that this.size is far clearer than _size. Using the underscored name does not prevent the subtle error, you can still assign size to itself, though hopefully your compiler will tell you. Commented May 22, 2011 at 14:14
  • 2
    Sure, you can always assign something to itself. The major difference between this.size and _size is consistency. With this.size is that it is optional. For example, if there was another private field called name, there is no need to use this.name in the code, I could just as easily use name without any clashes. Because this can be used sometimes, and not other times is why using this is inferior. On the other hand, there is no ambiguity with _ ... Commented May 22, 2011 at 14:23
  • 2
    Ugh...why do people still use the underscore in languages that provide a better way.
    – Rig
    Commented Mar 23, 2012 at 12:14

Consistency is really the key. That and clarity, i.e. don't be cryptic or try to save typing by abbreviating everything. Intellisense is your typing saver, not cryptic (but short!) names.

  • 2
    +1: Pick a convention and stick to it. Anything will do (except Systems Hungarian). Commented May 22, 2011 at 11:34
  • Consistency isn't the only thing. For example, someone can choose a consistent naming conventions for their own code, but if that convention is wildly different from other naming conventions, then when using other libraries ... there will inevitably be inconsistencies. For example, if I choose to use property naming conventions from C# in Java, I will not be consistent with how code is written in all other systems. I could write order.Size() (as opposed to order.getSize()) but since other libraries use getters and setters my code won't be consistent. Commented May 22, 2011 at 14:33
  • Obviously there should be some intelligent thought behind whatever conventions a person decides to use, but consistency is the most important thing.
    – richard
    Commented May 22, 2011 at 19:12
  • @DakotahNorth - it makes sense to have a house style, but beyond that, consistency is the key consideration. As long as the convention isn't too off-the-wall, it can be easily picked up by external/new developers. Indeed, it's worth publishing the house style, to remove any uncertainty.
    – cjmUK
    Commented Mar 23, 2012 at 14:17

In C# starting protected or public name with underscore is against Common Language Specification. It's correct only in case of private members.

From MSDN:

To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined.

See: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Here you can read warning about underscore:

Element names starting with an underscore (_) are not part of the Common Language Specification (CLS), so CLS-compliant code cannot use a component that defines such names. However, an underscore in any other position in an element name is CLS-compliant.

See: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Protected members are problem because you can inherit from class written in another language.

But maybe it's not problem in your case if you don't need CLS-compilant code.


I like the underscores. You know at first glance that the variable is a class member and private.

Sure the IDE can tell you that when you hover the mouse over it, but the "first glance" can't be beat. You know what's a local variable, and whats a member variable with your eyes alone. No scrolling or mouse hovers required.

You can use the "this" keyword but _ is shorter for better horizontal scanability. Descriptive names are usually desired but when something is an established convention it's better to have 1 character. for example using the letter i as the index when looping through an array. Since it's an established convention that i is an index, you get the benefit of scanability without the drawback of wondering what "i" means.


I agree generally with whats being said by other, however when it comes to tools and tools chains, I am lazy and like an easy life. I find life is often easier to just do it they way They suggest. The reasons are

  • It's easier to install (just go with defaults, even I can hit Enter 20 times and get it going)
  • The bugs have usually be worked out of the default settings, often its the esoteric configuration I set up that exposes a defect for the first time
  • The tool chain vendor probably knows more about it than me, therefore they made it that way for a reason. Who am I to decide the experts are wrong (I consider them experts, because I bought their tool)
  • You will never have to defend the vendors choice by a Manager - "It's what They recommend"
  • The new guy won't bug you with "why" and "It's better that way" - When every answer is "because They decided..."

So my take would be if you can find a valid reason to reconfigure the tools you just spent a fortune on, by all means do it. If you cannot justify making the change, don't.

Keep in mind that each and every change has an ongoing cost (real and hidden) to maintain. The less there are, the lower the cost. For instance - that new guy I mentioned - no changes means he can read their manual. Reconfigure - you have to write the addendum, store it away with otehr stuff, retireve it and get him to read it after reading their manual. Maybe not a problem for a 2 man shop, but what about a 100 man shop?


The two rules that you are asking about, underscore at the beginning of the private field names, and method names are generally regarded as the norm in C# development circles. By adapting to those conventions your code will be immediately more understandable to other developers because that is the frame of mind they are used to operating in.

The suffix of Label, RadioButton, etc. for your controls is generally regarded as the norm as well. Frequently multiple controls will exist for a single concept (e.g. a Label and a TextBox), and this suffix is quite useful. True Hungarian notation was abandoned long ago because it has been bastardized into something that does not express its original intent, which was context about the variable not what type, size, etc.


In my case, using camelcase and underscores helps with descriptive (read: long) variable names and code completion. I'm not quite sure how Visual Studio autocompletion works but in QtCreator and to a lesser extent, Eclipse, one can type, for example


and have it expanded to


Saves a bit of typing in case you have names like

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

which I tend to produce when in "descriptive naming mode".

Using underscores I can determine which name I want autocompleted




Hope my explanation is clear enough :)

Not the answer you're looking for? Browse other questions tagged or ask your own question.