#959 – Don’t Use Double Underscores at the Start of an Identifier
October 24, 2013 3 Comments
When naming identifiers in C#, you can use the underscore (‘_’) character anywhere in the identifier name, including at the beginning of the name.
Some people use identifiers that begin with a single underscore for private fields (e.g. _name, _age). This use is no longer recommend. You should instead just use camelCasing for private fields. If you want to make clear that the identifer is a member variable, you can use the this keyword (e.g. this.name, this.age).
You should, however, never use a double underscore at the start of an identifier name. There are already several reserved keywords that start with a double underscore (e.g. __reftype, __refvalue). The double underscore notation is meant to be used for these reserved keywords and future revisions to C# may add new keywords that may then conflict with any identifiers that you have in your code.
About Sean
2,000 Things You Should Know About C# 
Hi Sean,
why is it not recommended to use single underscore for private fields? Actually I switched from camelCase to _camelCase for my private Fields, since it makes finding my private fields in IntelliSense a lot easier. If I want to use my private field somewhere I just type ‘_’ and Intellisense shows me all my private fields instead of a whole bunch of fields, properties and methods.
Mainly just a convention. A bit cleaner, in that you’re not including some special character to tell you something about the category of identifier this is. Microsoft has shifted in this direction, away from having special characters mean special things. See http://msdn.microsoft.com/en-us/library/ms182245.aspx for the recommendation on avoiding underscores in identifiers.
I use _ in private fields and likely always will, *especially* with things like the CLR/CLI.
The reason is private fields are not completely “invisible” when you have full type information.
When I want a field to be private, usually in some sort of base class exported from a library, i do not want it in any way interfering with camel cased fields in derived classes.
And while I typically convert naming conventions for the environment – like switching from PascalCase to camelCase when moving to javascript or its variants like xml-case sometimes used in xml schemas, people don’t always convert those members to CamelCase.
Meaning camelCase happens – like if you’re building JSON wrappers and xml wrappers programatically. or working with that generated code.
You won’t find _camelCase fields in most cases under such a scenario *unless the cross environment framework is already doing case-aware munging.
meaning they’re “safe” ish when used with partial classes from generated code.