A few C# naming convention questions

Question

1) What's the policy for declaring a variable? Should you always use the keyword private, or is it OK to skip it?

string MyVar1;

vs.

private string MyVar1;

The only reason I see is that Microsoft one day can change the default access modifiers to public instead of private.

Where does it say that private is optional? Any references to MSDN?

2) Naming policy for constants?

I have always used caps when writing a constant, but a friend told me that it's against the Microsoft naming policy, is it?

const string MYVAR1;

vs

const string myVar1;

3) Pascal or Camel?

Personally I think that Camel just looks ugly.

Answer 1

1) The private keyword is optional. I highly doubt that Microsoft will ever change the default visibility of fields as this would be a massive, breaking change (not to mention a stupid one). Omitting the private keyword is merely a matter of personal taste.

2) Don't use "shouty" constants - follow the convention of the framework and use pascal casing (e.g. ThisIsAConstant is preferable over THIS_IS_A_CONSTANT).

Answer 2

private is optional, but extra typing. I like to skip it.

As for the constancts, It depends on your preferences and who you're working with. But when in doubt, look at the .NET Framework and how they name constants.

Answer 3

Also private field names should be in camel case, optionaly with prefix _ or m_ :

    private int count;
or
    private string _name;
or
    private decimal m_price;

Answer 4

I doubt Microsoft is ever going to change the default behavior for C# member variables. I would declare things private you want to be private and explicitly declare things public that you want to be public just for clarity if nothing else.

I think the important rule for constants is to just use a naming convention everyone agrees on and that you recognize as a constant. If everyone likes all upper case then use that. If you want to be more standard though use Pascal casing.

Answer 5

1) I tend to use private, just to be explicit, but there really is no need to I guess

2) It's true, Microsoft do recommend not using caps for constants.

Microsoft's naming convention gyuidelines for type members can be found here

Answer 6

You might be interested in Microsoft's Design Guidelines For Class Library Developers

Answer 7

private is optional, so you can skip it.

However, if your class has a mix of private, protected and public data members, it may be a good idea to specify that a member is private for the sake of readability.

Answer 8

Here's a free ebook with C# and VB .net coding guidelines, it's very good

Link to ebook download

Personally though, I like explicitly specifying when something is private, for readability, in fact I'm so used to doing so that when I don't see it I get confused. As for constants, I use PascalCasing.

Answer 9

Not answering your question directly, but maybe you would be interested in Microsoft's StyleCop. This is a tool for analysing your source code with respect to style and consistency rules. By default, it imposes Microsoft's styling guidelines.

Answer 10

Personally, I would love it if constants were ALL_CAPS like in some other languages...I think that it's an quick and easy way to spot constants. Nevertheless, since other constants built into the framework UsePascalCasing, you should too. Consistency is very important.

As far as "Pascal vs. Camel", you run into the same issue. If you were just programming on your own, from scratch, you could do whatever you wanted. But since you're using a preexisting framework, for the sake of consistency, you should emulate the same style. Additionally, once you get used to it, you'll probably find that following the same set of rules will actually help, because you'll instantly know that something is a parameter or local variable (camelCasing) vs a property or constant (PascalCasing).

Answer 11

Do use Pascal casing in field names.

From .NET Framework Developer's Guide Names of Type Members

Do use Pascal casing for all public member, type, and namespace names consisting of multiple words.

Note that this rule does not apply to instance fields. For reasons that are detailed in the Member Design Guidelines, you should not use public instance fields.

From .NET Framework Developer's Guide Capitalization Conventions

Note the implied standard of Pascal casing in constant naming.

DO use constant fields for constants that will never change.

The compiler burns the values of const fields directly into calling code. Therefore, const values can never be changed without the risk of breaking compatibility.

public struct Int32 {
  public const int MaxValue = 0x7fffffff;
  public const int MinValue = unchecked((int)0x80000000);
}

From Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Second Edition page 161

I cannot find any reference to whether you should decorate private fields with the term private. that is more of an internal style choice i would assume. Which ever you pick you will want to stay consistent.

Answer 12

You may also be interested in Microsoft's own Internal Coding Guidelines for the .NET Framework, as revealed by Brad Abrams in his blog:

Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

• Do not use Hungarian notation
• Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish
• between local and member variables you should use “this.” in C# and “Me.” in VB.NET.
• Do use camelCasing for member variables
• Do use camelCasing for parameters
• Do use camelCasing for local variables
• Do use PascalCasing for function, property, event, and class names
• Do prefix interfaces names with “I”
• Do not prefix enums, classes, or delegates with any letter

Answer 13

http://stackoverflow.com/questions/1228478/what-are-the-most-common-naming-conventions-in-c/1229290#1229290

Answer 14

@Dan Diplo # Do not use a prefix for member variables (, m, s_, etc.). If you want to distinguish # between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

That's highly arguable. Prefix helps intellisense: you put prefix char and get a list only of local private instance fields. With this. you will get a full list which consists of methods, fields, properties, events ect.

Consider also following example:

private int _count; 
private int total; 
private decimal price; 

public MyClass(int count, int total, decimal price) 
{ 
    _count = count;     // correct 
    this.total = total; // correct 
    price = price;      // wrong! you forgot this. qualifier 
}

Answer 15

In C# visibility defaults to the most limited visibility possible. Without a modifier:

• non-inner classes are internal
• inner classes are private
• class members are private

Because it's a good idea to limit visibility as much as possible anyway, I try to always leave off the modifier where the default visibility is all I need. This makes those members that aren't the default more obvious, which helps keep me attentive to whether they really need to be that visible.

For constants, my preference would be to put them in their own class(es) so that the ClassName.ConstantName format makes it obvious what they are.

In general I follow Microsoft's Design Guidelines for Developing Class Libraries.

Answer 16

The official recommendation for naming consts according to the MS guidelines, since no-one has actually specified it fully yet is:

• Use all caps for names with one or two characters i.e. System.Math.PI, System.Math.E
• For anything equal to or over 3 characters, use PascalCasing.