C# Naming Convention for Constants

C# naming convention for constants?

The recommended naming and capitalization convention is to use PascalCasing for constants (Microsoft has a tool named StyleCop that documents all the preferred conventions and can check your source for compliance - though it is a little bit too anally retentive for many people's tastes). e.g.

private const int TheAnswer = 42;

The Pascal capitalization convention is also documented in Microsoft's Framework Design Guidelines.

Naming Convention for constant Acronyms

The Framework Design Guidelines from Microsoft says:

The PascalCasing convention, used for all identifiers except parameter
names, capitalizes the first character of each word (including
acronyms over two letters in length), as shown in the following
examples:

PropertyDescriptor

HtmlTag

A special case is made for two-letter acronyms in which both letters
are capitalized, as shown in the following identifier:

IOStream

The camelCasing convention, used only for parameter names, capitalizes
the first character of each word except the first word, as shown in
the following examples. As the examples also shows, two-letter
acronyms that begin a camel-cased identifier are both lowercase:

propertyDescriptor

ioStream

htmlTag

But nevertheless, these are guidelines and conventions and not laws. If you like to take another convention, just use it. But then always and never mix up.

C# naming convention for constants other than Pascal and All Caps

In our projects we usally define a separate class for constants and use only Pascal naming for them.
So we refere constants something like this:

Functionality1Constants.ThisIsAConstant

Naming convention for class of constants in C#: plural or singular?

I would use the plural: Tokens. This implies that the static class is serving as a collection of items of some sort (whose runtime types are not that of the class).

On the other hand, an enumeration's fields are instances of the enumeration type. For example, TypeCode.String is a TypeCode. It would be weird to say that TypeCodes.String is a TypeCodes.

However, in your Tokens example, using the singular gives us Token.Foo, which is a token, but it is not a Token (it is a string).

(Or, if you use the plural class name, Tokens.Foo is a string, not a Tokens. Ack!)

What's the more elegant way to declare a const in C#

Ultimately the case isn't going to make any difference (unless it collides with a type/keyword/etc). So really consistency is the main thing.

The Capitalization Conventions don't distinguish between constants and other members - but these are guidelines only. So it would be pascal-case.

Naming convention for a variable that works like a constant

Encapsulate it.

#include <iostream>

class ParamFoo
{
    public:
        static void initializeAtStartup(double x);
        static double getFoo();
    private:
        static double foo_;
};

double ParamFoo::foo_;

void ParamFoo::initializeAtStartup(double x)
{
    foo_ = x;
}

double ParamFoo::getFoo()
{
    return foo_;
}

int main(void)
{
    ParamFoo::initializeAtStartup(0.4);
    std::cout << ParamFoo::getFoo() << std::endl;
}

This should make it pretty clear that you shouldn't be setting this value anywhere else but at the startup of the application. If you want added protection, you can add some private guard boolean variable to throw an exception if initializeAtStartup is called more than once.

Naming Convention for private const int ID property

http://msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.100).aspx

The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased
identifiers they should appear as Id, and Ok.

C# naming convention for initialized variable - are there special cases?

Microsoft has naming guidelines for most identifiers, but private variables are not included in those.

The most common convention is to use camel case for local variables:

WebImage uploadImage = WebImage.GetImageFromRequest();

There is no common convention for naming variables differently depending on whether they are initialised when they are declared or not. An uninitialised variable would eventually get initialised, making the naming confusing. Also, there is generally no need to single out uninitialised variables, as the compiler won't let you read a variable that is not known to definitely have been assigned.

On C# naming conventions for member variables

That is definitely a very popular naming convention and I don't see why you should be against it.

I would simply recommend following the Naming conventions for C# provided by MSDN and also General Naming Conventions provided by MSDN.

Specifically they have this to say about properties:

Do name properties using a noun, noun
phrase, or an adjective.

Noun phrases or adjectives are
appropriate for properties because
properties hold data.

Do not use properties that match the
names of Get methods.

For example do not name a property
EmployeeRecord and also name a method
GetEmployeeRecord. Developers will not
know which member to use to accomplish
their programming task.

Do name Boolean properties with an
affirmative phrase (CanSeek instead of
CantSeek). Optionally, you can also
prefix Boolean properties with Is,
Can, or Has, but only where it adds
value.

Consider giving a property the same
name as its type.

When you have a property that is
strongly typed to an enumeration, the
name of the property can be the same
as the name of the enumeration. For
example, if you have an enumeration
named CacheLevel, a property that
returns one of its values can also be
named CacheLevel.

I think if there were a compelling reason to be against what you are suggesting they would have mentioned it in their guidelines.

---

Related Topics