private const int THE_ANSWER = 42;
or
private const int theAnswer = 42;
Personally I think with modern IDEs we should go with camelCase as ALL_CAPS looks strange. What do you think?
This question is related to
c#
naming-conventions
constants
I actually tend to prefer PascalCase here - but out of habit, I'm guilty of UPPER_CASE...
Actually, it is
private const int TheAnswer = 42;
At least if you look at the .NET library, which IMO is the best way to decide naming conventions - so your code doesn't look out of place.
In its article Constants (C# Programming Guide), Microsoft gives the following example:
class Calendar3
{
const int months = 12;
const int weeks = 52;
const int days = 365;
const double daysPerWeek = (double) days / (double) weeks;
const double daysPerMonth = (double) days / (double) months;
}
So, for constants, it appears that Microsoft is recommending the use of camelCasing. But note that these constants are defined locally.
Arguably, the naming of externally-visible constants is of greater interest. In practice, Microsoft documents its public constants in the .NET class library as fields. Here are some examples:
static readonly)The first two are examples of PascalCasing. The third appears to follow Microsoft's Capitalization Conventions for a two-letter acronym (although pi is not an acryonym). And the fourth one seems to suggest that the rule for a two-letter acryonym extends to a single letter acronym or identifier such as E (which represents the mathematical constant e).
Furthermore, in its Capitalization Conventions document, Microsoft very directly states that field identifiers should be named via PascalCasing and gives the following examples for MessageQueue.InfiniteTimeout and UInt32.Min:
public class MessageQueue
{
public static readonly TimeSpan InfiniteTimeout;
}
public struct UInt32
{
public const Min = 0;
}
Conclusion: Use PascalCasing for public constants (which are documented as const or static readonly fields).
Finally, as far as I know, Microsoft does not advocate specific naming or capitalization conventions for private identifiers as shown in the examples presented in the question.
The ALL_CAPS is taken from the C and C++ way of working I believe. This article here explains how the style differences came about.
In the new IDE's such as Visual Studio it is easy to identify the types, scope and if they are constant so it is not strictly necessary.
The FxCop and Microsoft StyleCop software will help give you guidelines and check your code so everyone works the same way.
First, Hungarian Notation is the practice of using a prefix to display a parameter's data type or intended use. Microsoft's naming conventions for says no to Hungarian Notation http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx
Using UPPERCASE is not encouraged as stated here: Pascal Case is the acceptable convention and SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming
Microsoft also states here that UPPERCASE can be used if it is done to match the the existed scheme. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx
This pretty much sums it up.
The ALL_CAPS is taken from the C and C++ way of working I believe. This article here explains how the style differences came about.
In the new IDE's such as Visual Studio it is easy to identify the types, scope and if they are constant so it is not strictly necessary.
The FxCop and Microsoft StyleCop software will help give you guidelines and check your code so everyone works the same way.
First, Hungarian Notation is the practice of using a prefix to display a parameter's data type or intended use. Microsoft's naming conventions for says no to Hungarian Notation http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx
Using UPPERCASE is not encouraged as stated here: Pascal Case is the acceptable convention and SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming
Microsoft also states here that UPPERCASE can be used if it is done to match the the existed scheme. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx
This pretty much sums it up.
Leave Hungarian to the Hungarians.
In the example I'd even leave out the definitive article and just go with
private const int Answer = 42;
Is that answer or is that the answer?
*Made edit as Pascal strictly correct, however I was thinking the question was seeking more of an answer to life, the universe and everything.
Visually, Upper Case is the way to go. It is so recognizable that way. For the sake of uniqueness and leaving no chance for guessing, I vote for UPPER_CASE!
const int THE_ANSWER = 42;
Note: The Upper Case will be useful when constants are to be used within the same file at the top of the page and for intellisense purposes; however, if they were to be moved to an independent class, using Upper Case would not make much difference, as an example:
public static class Constant
{
public static readonly int Cons1 = 1;
public static readonly int coNs2 = 2;
public static readonly int cOns3 = 3;
public static readonly int CONS4 = 4;
}
// Call constants from anywhere
// Since the class has a unique and recognizable name, Upper Case might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
}
Actually, it is
private const int TheAnswer = 42;
At least if you look at the .NET library, which IMO is the best way to decide naming conventions - so your code doesn't look out of place.
I still go with the uppercase for const values, but this is more out of habit than for any particular reason.
Of course it makes it easy to see immediately that something is a const. The question to me is: Do we really need this information? Does it help us in any way to avoid errors? If I assign a value to the const, the compiler will tell me I did something dumb.
My conclusion: Go with the camel casing. Maybe I will change my style too ;-)
Edit:
That something smells hungarian is not really a valid argument, IMO. The question should always be: Does it help, or does it hurt?
There are cases when hungarian helps. Not that many nowadays, but they still exist.
I actually tend to prefer PascalCase here - but out of habit, I'm guilty of UPPER_CASE...
Leave Hungarian to the Hungarians.
In the example I'd even leave out the definitive article and just go with
private const int Answer = 42;
Is that answer or is that the answer?
*Made edit as Pascal strictly correct, however I was thinking the question was seeking more of an answer to life, the universe and everything.
First, Hungarian Notation is the practice of using a prefix to display a parameter's data type or intended use. Microsoft's naming conventions for says no to Hungarian Notation http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx
Using UPPERCASE is not encouraged as stated here: Pascal Case is the acceptable convention and SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming
Microsoft also states here that UPPERCASE can be used if it is done to match the the existed scheme. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx
This pretty much sums it up.
I actually tend to prefer PascalCase here - but out of habit, I'm guilty of UPPER_CASE...
I still go with the uppercase for const values, but this is more out of habit than for any particular reason.
Of course it makes it easy to see immediately that something is a const. The question to me is: Do we really need this information? Does it help us in any way to avoid errors? If I assign a value to the const, the compiler will tell me I did something dumb.
My conclusion: Go with the camel casing. Maybe I will change my style too ;-)
Edit:
That something smells hungarian is not really a valid argument, IMO. The question should always be: Does it help, or does it hurt?
There are cases when hungarian helps. Not that many nowadays, but they still exist.
In its article Constants (C# Programming Guide), Microsoft gives the following example:
class Calendar3
{
const int months = 12;
const int weeks = 52;
const int days = 365;
const double daysPerWeek = (double) days / (double) weeks;
const double daysPerMonth = (double) days / (double) months;
}
So, for constants, it appears that Microsoft is recommending the use of camelCasing. But note that these constants are defined locally.
Arguably, the naming of externally-visible constants is of greater interest. In practice, Microsoft documents its public constants in the .NET class library as fields. Here are some examples:
static readonly)The first two are examples of PascalCasing. The third appears to follow Microsoft's Capitalization Conventions for a two-letter acronym (although pi is not an acryonym). And the fourth one seems to suggest that the rule for a two-letter acryonym extends to a single letter acronym or identifier such as E (which represents the mathematical constant e).
Furthermore, in its Capitalization Conventions document, Microsoft very directly states that field identifiers should be named via PascalCasing and gives the following examples for MessageQueue.InfiniteTimeout and UInt32.Min:
public class MessageQueue
{
public static readonly TimeSpan InfiniteTimeout;
}
public struct UInt32
{
public const Min = 0;
}
Conclusion: Use PascalCasing for public constants (which are documented as const or static readonly fields).
Finally, as far as I know, Microsoft does not advocate specific naming or capitalization conventions for private identifiers as shown in the examples presented in the question.
I still go with the uppercase for const values, but this is more out of habit than for any particular reason.
Of course it makes it easy to see immediately that something is a const. The question to me is: Do we really need this information? Does it help us in any way to avoid errors? If I assign a value to the const, the compiler will tell me I did something dumb.
My conclusion: Go with the camel casing. Maybe I will change my style too ;-)
Edit:
That something smells hungarian is not really a valid argument, IMO. The question should always be: Does it help, or does it hurt?
There are cases when hungarian helps. Not that many nowadays, but they still exist.
Actually, it is
private const int TheAnswer = 42;
At least if you look at the .NET library, which IMO is the best way to decide naming conventions - so your code doesn't look out of place.
The ALL_CAPS is taken from the C and C++ way of working I believe. This article here explains how the style differences came about.
In the new IDE's such as Visual Studio it is easy to identify the types, scope and if they are constant so it is not strictly necessary.
The FxCop and Microsoft StyleCop software will help give you guidelines and check your code so everyone works the same way.
I still go with the uppercase for const values, but this is more out of habit than for any particular reason.
Of course it makes it easy to see immediately that something is a const. The question to me is: Do we really need this information? Does it help us in any way to avoid errors? If I assign a value to the const, the compiler will tell me I did something dumb.
My conclusion: Go with the camel casing. Maybe I will change my style too ;-)
Edit:
That something smells hungarian is not really a valid argument, IMO. The question should always be: Does it help, or does it hurt?
There are cases when hungarian helps. Not that many nowadays, but they still exist.
Visually, Upper Case is the way to go. It is so recognizable that way. For the sake of uniqueness and leaving no chance for guessing, I vote for UPPER_CASE!
const int THE_ANSWER = 42;
Note: The Upper Case will be useful when constants are to be used within the same file at the top of the page and for intellisense purposes; however, if they were to be moved to an independent class, using Upper Case would not make much difference, as an example:
public static class Constant
{
public static readonly int Cons1 = 1;
public static readonly int coNs2 = 2;
public static readonly int cOns3 = 3;
public static readonly int CONS4 = 4;
}
// Call constants from anywhere
// Since the class has a unique and recognizable name, Upper Case might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
}
Leave Hungarian to the Hungarians.
In the example I'd even leave out the definitive article and just go with
private const int Answer = 42;
Is that answer or is that the answer?
*Made edit as Pascal strictly correct, however I was thinking the question was seeking more of an answer to life, the universe and everything.
The ALL_CAPS is taken from the C and C++ way of working I believe. This article here explains how the style differences came about.
In the new IDE's such as Visual Studio it is easy to identify the types, scope and if they are constant so it is not strictly necessary.
The FxCop and Microsoft StyleCop software will help give you guidelines and check your code so everyone works the same way.
First, Hungarian Notation is the practice of using a prefix to display a parameter's data type or intended use. Microsoft's naming conventions for says no to Hungarian Notation http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx
Using UPPERCASE is not encouraged as stated here: Pascal Case is the acceptable convention and SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming
Microsoft also states here that UPPERCASE can be used if it is done to match the the existed scheme. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx
This pretty much sums it up.
Actually, it is
private const int TheAnswer = 42;
At least if you look at the .NET library, which IMO is the best way to decide naming conventions - so your code doesn't look out of place.
I actually tend to prefer PascalCase here - but out of habit, I'm guilty of UPPER_CASE...
Leave Hungarian to the Hungarians.
In the example I'd even leave out the definitive article and just go with
private const int Answer = 42;
Is that answer or is that the answer?
*Made edit as Pascal strictly correct, however I was thinking the question was seeking more of an answer to life, the universe and everything.
Source: Stackoverflow.com