1

For those of you that use the underscore prefix for private class members in C# (i.e. private int _count;), what do you use for private constants? I'm thinking the following but am curious as to what others are doing.

private const int _MaxCount;
bsh152s
  • 3,178
  • 6
  • 51
  • 77
  • Asked before at http://stackoverflow.com/questions/242534/c-naming-convention-for-constants But I see from Martin's answer he's already been there. ;) – Xiaofu Aug 20 '09 at 13:41
  • In fact I haven't been there - otherwise I would have used TheAnswer as the name of the constant ;-) – M4N Aug 20 '09 at 13:43
  • Good point, so my apologies. If my brain didn't hurt so much I should have expected that 42 is always the answer when you need a random number. But what was the question? – Xiaofu Aug 20 '09 at 13:47

4 Answers4

5

Well, private is private, so chose the convention you like best. I personally use PascalCasing, e.g:

private const int SomeConstant = 42;

This is what MSDN has to say about it:

The naming guidelines for fields apply to static public and protected fields. You should not define public or protected instance fields:

  • Do use Pascal casing in field names.
  • Do name fields with nouns or noun phrases.
  • Do not use a prefix for field names. For example, do not use g_ or s_ to distinguish static versus non-static fields.
M4N
  • 94,805
  • 45
  • 217
  • 260
  • It says: use `camelCase` for private fields (constants are technically fields too): http://msdn.microsoft.com/en-us/library/x2dbyw72(VS.71).aspx – Mehrdad Afshari Aug 20 '09 at 14:01
  • 1
    The problem I have with this is that Pascal casing is also used for Properties. I'd like to look at a variable and know it is a variable, not a property. – bsh152s Aug 20 '09 at 14:07
3

I'm using:

private const int MAX_COUNT = 42;

I do not use PascalCasing because that's my standard for properties.
I do not use camelCasing because that's my standard for local variables.
I do not use _camelCasing because that's my standard for private fields.
I do not use _PascalCasing because IMO it's hard to distinguish it from _camelCasing.

HuBeZa
  • 4,715
  • 3
  • 36
  • 58
2

C# and .NET naming conventions discourage all prefixes (e.g. C, i, s_, g_, m_, _) except "I" for interface names and "T" for type parameters.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • 1
    And a T prefix for generic types? – Charlie Aug 20 '09 at 13:38
  • Do you have a reference to that? As far as I remember these conventions only cover the public parts, but not private. – M4N Aug 20 '09 at 13:38
  • Charlie: Yeah. I missed that one. Thanks for pointing it out. Actually, not the types themselves. T for type parameters. – Mehrdad Afshari Aug 20 '09 at 13:39
  • Martin: There's a naming convention document out there. The thing you are mentioning is the common language specification naming standards. They are actually **enforced** if you want your assembly to be `[CLSCompliant(true)]` and they only cover public names but the conventions apply to all cases (and they are just conventions.) – Mehrdad Afshari Aug 20 '09 at 13:41
  • 1
    I'm not quite sure I understand why prefixes are discouraged? If I don't use them, I can't immediately identify that a variable is a class variable or a local variable. – bsh152s Aug 20 '09 at 13:54
  • Brandon: I can think of some reasons but I'm just quoting the .NET framework naming guidelines published by MS. This is their decision. – Mehrdad Afshari Aug 20 '09 at 13:57
0

The naming guidelines are available here:
http://msdn.microsoft.com/en-us/library/ms229002.aspx

As Mehrdad said, prefixes are specifically discouraged.

That said, they are just guidelines more than hard rules. Personally, I use an '_' prefix, but only for private members that directly provide the backing store for a public property, and then the names will otherwise match exactly.

There's no specific guidance for constants, so the Capitalization Conventions rules probably still fit.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794