35

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.

Improve this question
9
  • 48
    Grain of salt when reading answers here: Follow your org's existing code - don't try to go against the grain. If you get a chance to give input then go for it, but don't waste effort on trivial things like fighting existing naming conventions (unless you're sufficiently isolated from existing code), or trying to modify them in existing code (except in a code review pre-check in, modifying it to fit existing conventions). You'll be very unproductive, and anger people while you're at it :) Commented Nov 4, 2011 at 9:19
  • 3
    I don't think @Shogoot intents to change it! It is good that he questions what it is. Commented Nov 4, 2011 at 17:07
  • For most the private fields, it is appropriate to use _ underscore before the variable names. Commented Nov 8, 2011 at 17:06
  • @Braveyard: He can use camel case notations too. It depends on organizations to organizations that what are your coding policies. Commented Nov 8, 2011 at 18:06
  • 2
    I will never understand why on earth use _ or some m prefix in member variables. If if it makes anything more readable for you that means your code is bad, classes and methods are too big and you have never heard of SRP. Commented Nov 8, 2011 at 20:40

12 Answers 12

Reset to default
34

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

According to this document, it is ok.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

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.
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.
The main reason to use a leading underscore on a private member is to avoid a naming conflict with a public accessor.
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.
@EricLiprandi ...until you try running StyleCop on that code.
|
26

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.

Improve this answer

8 Comments

There is also a similar page for style guidelines blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx
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...
@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
+1 for prioritizing readability (even over style guidelines for private class members).
@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.
|
21

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.

Improve this answer

1 Comment

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

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.

Improve this answer

5 Comments

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 :-)
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.
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
The later link you've shown says: "The naming guidelines for fields apply to static public and protected fields."
That Cheat Sheet in the first link is very useful.
8

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?

Improve this answer

1 Comment

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

_name is messy, confusing and very old-style. don't do it.

.NET 4.0 General Naming Conventions http://msdn.microsoft.com/en-us/library/ms229045.aspx

as you can see, MSDN states

Do not use underscores, hyphens, or any other nonalphanumeric characters

Improve this answer

9 Comments

+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...
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
downvoters could at least leave a comment to clearly state why they disagree with Microsoft itself
-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.
-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.
|
4

That is relatively common in my experience. To help identify particular kinds of variables (privates, method parameters etc.), a developer may employ different naming conditions.

e.g.

  • VariableName
  • variableName (camel case)
  • _variable
  • VARIABLE_NAME

It tends to vary by company I think.

Improve this answer

2 Comments

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).
Yes you are right there actually thanks (on pascal/camel case)
3

I like to use a case change to distinguish between fields and properties:

// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
    get { return someValue; }
    set { someValue = value; }
}
Improve this answer

Comments

3

Are your co-workers ex-VB devs? In VB.Net the underscore is used regularly for private members of properties or classes. Since VB is case insensitive, you can't use case to distinguish.

Private _someValue As Boolean
Protected Property SomeValue() As Boolean
    Get
        Return _someValue
    End Get
    Set(ByVal value As Boolean)
        _someValue = value
    End Set
End Property

Update: As an aside, many classes in the .NET source code use this convention. Especially in System.Web.

Improve this answer

Comments

2

There are two common conventions.

the first is "User underscore as field marker" the second is "Use s_ for static fields and m_ for intance fields"

imo this is a religious question and onnly important thing is to not mix up both styles.

This book contains many good ideas about convention and design guidelines

http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=sr_1_1?ie=UTF8&qid=1320395003&sr=8-1

Improve this answer

Comments

1

There are many naming conventions that people follow

myFirstVar = Camel Notation

Camel notaion is generally used for public variables (not private variables).

MyFirstVar = Pascal Notation

Pascal is generally used for naming Classes and Methods.

str_MyFirstVar = Hungarian Notation // if variable is of type string

Hungarian Notation is considered to be the oldest but not used anymore.

_myFirstVariable = used for private fields in general
Improve this answer

1 Comment

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.
1

According to StyleCop [A style/convention checking tool by Microsoft) it shouldn't be done. See: http://stylecop.soyuz5.com/SA1309.html

Also, question is a possible dupe of To underscore or to not to underscore, that is the question

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.