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.

Mike Woodhouse
  • 51,832
  • 12
  • 88
  • 127
Shogoot
  • 297
  • 2
  • 6
  • 13
  • 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 :) – Merlyn Morgan-Graham Nov 04 '11 at 09:19
  • 3
    I don't think @Shogoot intents to change it! It is good that he questions what it is. – Angelo Nov 04 '11 at 17:07
  • For most the private fields, it is appropriate to use `_` underscore before the variable names. – Tarik Nov 08 '11 at 17:06
  • @Braveyard: He can use camel case notations too. It depends on organizations to organizations that what are your coding policies. – RG-3 Nov 08 '11 at 18:06
  • We actually use Hungarian Notations and kinda like it for private members as well. `(msName as String)` – Tarik Nov 08 '11 at 18:25
  • 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. – Piotr Perak Nov 08 '11 at 20:40
  • @Braveyard: Hungarian notation does not encode physical types in variable names. – Piotr Perak Nov 08 '11 at 20:42
  • @Prei, Braveyar: It depends on who you ask... http://en.wikipedia.org/wiki/Hungarian_notation – Merlyn Morgan-Graham Nov 10 '11 at 08:15
  • Am I the only one here who was a long time `_name` follower before I converted to `justNameIt` religion? And am I the only one in the process believe MS should be considered an outcast for having `IType`s? – nawfal Apr 21 '13 at 18:46

12 Answers12

34

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

According to this document, it is ok.

sshow
  • 8,820
  • 4
  • 51
  • 82
Manu
  • 1,130
  • 3
  • 10
  • 26
  • 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 Nov 04 '11 at 09:13
  • 19
    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. – Jon Skeet Nov 04 '11 at 09:24
  • 1
    The main reason to use a leading underscore on a `private` member is to avoid a naming conflict with a `public` accessor. – Simon Richter Nov 04 '11 at 11:39
  • 4
    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. – Eric Liprandi Nov 04 '11 at 12:10
  • @EricLiprandi ...until you try running StyleCop on that code. – user Nov 04 '11 at 13:50
  • 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. – BlueRaja - Danny Pflughoeft Nov 04 '11 at 18:26
  • Reflector also enforces this... Not that Reflector is the best when dictating code style and best practices, but it is used widely. – casperOne Nov 07 '11 at 12:50
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.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    There is also a similar page for style guidelines http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx – Firedragon Nov 04 '11 at 08:49
  • It probably helps to keep your classes small enough (applying [SRP](http://en.wikipedia.org/wiki/Single_responsibility_principle) 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... – Mike Woodhouse Nov 04 '11 at 10:05
  • @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 – Chris S Nov 04 '11 at 14:56
  • +1 for prioritizing readability (even over style guidelines for private class members). – Roy Tinker Nov 04 '11 at 16:55
  • 1
    @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. – CodesInChaos Nov 06 '11 at 16:05
  • You forgot to add that adding prefixes is great for eliminating intellisense in VS – Piotr Perak Nov 08 '11 at 20:45
  • 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 – nawfal Apr 21 '13 at 18:40
  • @nawfal: I'm not keen on the `mVariable` part, I *do* like interface prefixing. I find it handy for clarity. YMMV of course. – Jon Skeet Apr 21 '13 at 18:44
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.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
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.

John Weldon
  • 39,849
  • 11
  • 94
  • 127
  • 2
    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 Nov 04 '11 at 08:46
  • 1
    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 Nov 04 '11 at 09:11
  • 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 – John Weldon Nov 04 '11 at 09:46
  • The later link you've shown says: "The naming guidelines for fields apply to static public and protected fields." – Jon Skeet Nov 04 '11 at 10:29
  • That Cheat Sheet in the first link is very useful. – Otiel Nov 04 '11 at 10:54
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?

Miika L.
  • 3,333
  • 1
  • 24
  • 35
  • 1
    +1. I think any developer joining a project should try and get hold of the standards very early on in joining a project. – Firedragon Nov 04 '11 at 09:03
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.

sshow
  • 8,820
  • 4
  • 51
  • 82
glosrob
  • 6,631
  • 4
  • 43
  • 73
  • 2
    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). – Merlyn Morgan-Graham Nov 04 '11 at 08:23
  • Yes you are right there actually thanks (on pascal/camel case) – glosrob Nov 04 '11 at 08:27
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

Alex
  • 23,004
  • 4
  • 39
  • 73
  • 5
    +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... – Merlyn Morgan-Graham Nov 04 '11 at 08:27
  • 2
    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 – Alex Nov 04 '11 at 09:11
  • 1
    downvoters could at least leave a comment to clearly state why they disagree with Microsoft itself – Alex Nov 10 '11 at 08:07
  • -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. – Chad Dec 14 '11 at 14:17
  • @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. – Alex Dec 14 '11 at 16:38
  • 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. – Chad Dec 14 '11 at 16:59
  • @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? – nicodemus13 Jan 07 '15 at 16:46
  • @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. – Chad Jan 07 '15 at 19:42
  • 1
    -1. This Microsoft convention states nothing about `private` members. This convention relates only to externally visible members (as stated in [this comment](http://stackoverflow.com/questions/8006494/c-sharp-net-instance-variable-naming-convention#comment9827591_8006532) too). OP question is about `private` members. – Frédéric Oct 08 '15 at 13:55
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; }
}
Otiel
  • 18,404
  • 16
  • 78
  • 126
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.

James Lawruk
  • 30,112
  • 19
  • 130
  • 137
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

Boas Enkler
  • 12,264
  • 16
  • 69
  • 143
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

Community
  • 1
  • 1
Ron Sijm
  • 8,490
  • 2
  • 31
  • 48
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
Sandy
  • 11,332
  • 27
  • 76
  • 122
  • 1
    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. – Merlyn Morgan-Graham Nov 04 '11 at 09:14