C# .NET instance variable naming convention?

Question

I'm doing a small internship at a business and in their code I find classes that are named like this:

public class FlagsConfig
{
    private static FlagsConfig _instance; 
}

Is the _instance a naming convention of any sort in C#?

I would ask the developers but they are all out today and the next week on some course.

Solution 1

Maybe this can help you: .net Naming Conventions and Programming Standards - Best Practices

According to this document, it is ok.

Solution 2

For private members, there are lots of different conventions. Some people like prefixes, some don't (personally I don't). Some like to differentiate between instance variables and static variables, others don't:

private string m_foo;
private static string s_foo;

Personally I find the underscores get in the way when I'm reading the text - and I firmly believe it depends on how you read; I subvocalize when I read, and the extra bits get in the way of that. For others, it's clearly not a problem. Others find the lack of distinction between local variables and member variables a problem - I typically write short methods where it's obvious what's what anyway.

What's more important - certainly if you're creating an API etc is the naming of publicly visible members (which includes protected ones, and parameter names) at which point you should look at the Microsoft guidelines.

Solution 3

Is the _instance a naming convention of any sort in C#?

First off, a number of people have referenced the naming guidelines. Note that many of those guidelines apply only to the public surface area of a type. Private members like the one you mention are internal implementation details and therefore subject to the policies of the organization that produced them, not subject to the framework design guidelines for what people expect to see in a public element.

For private implementation details the underbar prefix is common in many organizations. I personally don't think it is necessary, but some people seem to like it.

What is important however is that even for private implementation details you should never use two underbars. The C# compiler team reserves the right to make any word that begins with two underbars to have any meaning we choose in some future version of the language. That is our "escape hatch" in case we really, really need to add a new non-contextual reserved keyword and really, really do not want to break any existing code.

This is documented in section 2.4.2 of the C# 4 specification.

Solution 4

Yes, that is a common naming standard for private fields:

http://csharpguidelines.codeplex.com/

I happen to agree with @JonSkeet that the underscores are messy, but AFAIK that is the MS standard. The document he links to indicates not using underscores in your library, but I believe that is referring to public members.

Update

The first link actually advocates the opposite; don't use underscores. My mistake, but it's still a useful resource.

In deference to Mr. Skeet, I followed his link further to: http://msdn.microsoft.com/en-us/library/ms229012.aspx which also states that you shouldn't use underscores, but that guidance applies to static, protected and public members, but not necessarily to private members.

Bottom Line: Yes it is a common standard, but first use any internally agreed upon standard before trying to find/use external standards.

Solution 5

There are many guidelines and standards to choose from, but if the standard used at your workplace uses underscores, then that is what you need to use. Especially if you are only doing an internship there, the goal should be to keep things consistent (within that business) rather than following some standard which is "better" (but different).

Perhaps the better question to ask your developers (or the higher up bosses) is if they have any documentation/links on the standards that they do use?

View more solutions

Comments

[Merlyn Morgan-Graham]

Or in a few companies I've worked at, by group or by person :) BTW, the first I believe is called PascalCase, whereas the second is called camelCase (short at the front, humps in the middle - like a camel).

[glosrob]

Yes you are right there actually thanks (on pascal/camel case)

[Merlyn Morgan-Graham]

+1; While I agree with your sentiment, and like your reference, this particular case is sort of a holy war. Under dispute, and producing more heat than light...

[Firedragon]

Doesn't that coding standard actually say not to use an underscore for private fields though? Although as others have said the way to go is always look at your teams coding standards first :-)

[Firedragon]

There is also a similar page for style guidelines blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

[Firedragon]

+1. I think any developer joining a project should try and get hold of the standards very early on in joining a project.

[Alex]

for me, it's a matter of laziness: if my code can "tell" readers what it does i don't have to :) underscores and prefixes are bound to me misunderstood at some point

[Shogoot]

Since the business im @ uses the _ to denote private fields of classes it is not a question of NOT using it. The question is anyways answered as use of _ IS a naming convention, evnen if its not recoemnded by the documents you people have linked.

[Shogoot]

Since the business im @ uses the _ to denote private fields of classes it is not a question of NOT using it. The question is anyways answered as use of _ IS a naming convention, evnen if its not recoemnded by the documents you people have linked.

[Merlyn Morgan-Graham]

Pascal is used for public properties too, as they are technically methods in disguise. Public member variables generally shouldn't be used, ever, as they tie your hands.

[Jon Skeet]

It's worth noting that you can probably find some document on the internet advocating just about whatever style you want to use... there's no indication of how widely followed any particular document is.

[John Weldon]

In which case the answer is... Yes. It is a common naming standard. For example, it's the default for the popular c# tool ReSharper

[Mike Woodhouse]

It probably helps to keep your classes small enough (applying SRP can help) that instance variable definitions are seldom more than a flick of the eyes (or maybe a PageUp) away. Advice I should take more often myself...

[Jon Skeet]

The later link you've shown says: "The naming guidelines for fields apply to static public and protected fields."

[Otiel]

That Cheat Sheet in the first link is very useful.

[Simon Richter]

The main reason to use a leading underscore on a private member is to avoid a naming conflict with a public accessor.

[Eric Liprandi]

For what it's worth, I used to be against the whole underscore thing. I thought lowercase and uppercase were just fine to distinguish between Properties and variables. That was until I kept running into the construtor parameters and you want to assign that parameter to a private field. private object something; public Ctor(object something){ this.something = something;}. As you can see, it does work, but you have to specify the this keyword every time. That makes a bit more sense to use the _something notation for private fields.

[user]

@EricLiprandi ...until you try running StyleCop on that code.

[MordechayS]

@Firedragon that's an interesting link, particularly as it looks like Microsoft didn't follow their own guidelines when creating the framework - it's riddled with m_ variable names

[Roy Tinker]

+1 for prioritizing readability (even over style guidelines for private class members).

[BlueRaja - Danny Pflughoeft]

From that article: "Microsoft recommends against the m_ (and the straight _) even though they did both in their code." Though for the record, I also prefer using _ to preceed my private variables.

[configurator]

Is that the reason the undocumented __arglist and TypedReference keywords all start with __?

[CodesInChaos]

@ChrisS The general naming guidelines only apply to the public surface area(public/protected members). I think what Firedragon linked are internal guidelines for one specific team in MS, not for MS in general.

[casperOne]

Reflector also enforces this... Not that Reflector is the best when dictating code style and best practices, but it is used widely.

[Piotr Perak]

You forgot to add that adding prefixes is great for eliminating intellisense in VS

[Alex]

downvoters could at least leave a comment to clearly state why they disagree with Microsoft itself

[Chad]

-1 not every team uses the Microsoft naming convention. It is not the developers place to change the naming conventions of existing code because they prefer a different one. In addition just mixing conventions like using the java(Which is what i suspect they are) convention and the MS Convention can make even more confusing code.

[Alex]

@Chad OP asked if _name is part of C# convention. The answer is no. I don't see any reference to java in the question.

[Chad]

C# doesn't care. It doesn't care if you use obfuscated class names as long as it works syntactically... There are a many places that use that convention your advice not to use it despite that being the convention that his group is currently using is bad advice you asked for a reason I gave it to you.

[nawfal]

While MS is appropriate in preferring what they did, I don't understand how is mVariable bad and IType good - Java got it right, just name what they are and not denote/notate

[Jon Skeet]

@nawfal: I'm not keen on the mVariable part, I do like interface prefixing. I find it handy for clarity. YMMV of course.

[nicodemus13]

@Chad: 'It is not the developers place to change the naming conventions of existing code because they prefer a different one.' If it's not the developers' place, I can't see whose it is. Or do you mean an individual developer over the agreed convention?

[Chad]

@nicodemus13 - Yes the individual developer. Of course if the developer is tasked with that specifically then it would be different. But Just coming in and changing the naming convention of an existing codebase is not going to make you any friends unless you have that mandate.

[Frédéric]

-1. This Microsoft convention states nothing about private members. This convention relates only to externally visible members (as stated in this comment too). OP question is about private members.