propper casing of a constant

  • Thread starter Thread starter Smokey Grindle
  • Start date Start date
S

Smokey Grindle

I always learned when you have a constant name it in all upper case like
this
PASSWORD_MAXIMUM_LENGTH

but FxCop is saying this isn't correct, but doesnt tell me the correct
"accepted" way in .net to name a constant... what is it?
 
Smokey Grindle said:
I always learned when you have a constant name it in all upper case
like this
PASSWORD_MAXIMUM_LENGTH

but FxCop is saying this isn't correct, but doesnt tell me the
correct "accepted" way in .net to name a constant... what is it?


There is no "correct". It's up to you, but you should make it consistently.
I prefer PasswordMaximumLength and probably most sources use it.


Armin
 
I always learned when you have a constant name it in all upper case like
this
PASSWORD_MAXIMUM_LENGTH

but FxCop is saying this isn't correct, but doesnt tell me the correct
"accepted" way in .net to name a constant... what is it?

Armin, most sources don't use ThisNotationAtAll.

You can do what you want but consistency will make you feel more at
home. Probably the most widely used and my personal favourite is
CONSTANT_NAME_IN_CAPITALS_WITH_UNDERSCORE.

This also provides more consistency than Armins approach as well since
as Microsoft use this convention and the library defines thousands of
constants in this fashion.
 
Constants are cased the same as variables in the camel/Pascal naming standards.
A constant is recognized by its carefully-selected name and (to a lesser
extent) how it is treated by IntelliSense and the compiler.
 
Phillip Taylor said:
Armin, most sources don't use ThisNotationAtAll.

You can do what you want but consistency will make you feel more at
home. Probably the most widely used and my personal favourite is
CONSTANT_NAME_IN_CAPITALS_WITH_UNDERSCORE.

This also provides more consistency than Armins approach as well
since as Microsoft use this convention and the library defines
thousands of constants in this fashion.

This is not correct. For example, I see these constants:

System.Byte.MaxValue
System.Byte.MinValue

System.TimeSpan.TicksPerMillisecond
System.TimeSpan.TicksPerDay

System.Resources.ResXResourceWriter.BinSerializedObjectMimeType
System.Resources.ResXResourceWriter.ByteArraySerializedObjectMimeType
System.Resources.ResXResourceWriter.DefaultSerializedObjectMimeType

System.Windows.Forms.ListBox.DefaultItemHeight
System.Windows.Forms.ListBox.NoMatches

System.Windows.Forms.Menu.FindHandle
System.Windows.Forms.Menu.FindShortcut

All constants are written this way. In addition, all the Enum items (which
are constants either). CAPITALS are sometimes still used with constants for
calling API functions, but not in the .Net world anymore.


Armin
 
Constants are cased the same as variables in the camel/Pascal naming standards.
A constant is recognized by its carefully-selected name and (to a lesser
extent) how it is treated by IntelliSense and the compiler.

Welcome back Tim! I was starting to wonder what happened to you.

Thanks,

Seth Rowe
 
Armin, most sources don't use ThisNotationAtAll.

You can do what you want but consistency will make you feel more at
home. Probably the most widely used and my personal favourite is
CONSTANT_NAME_IN_CAPITALS_WITH_UNDERSCORE.

This also provides more consistency than Armins approach as well since
as Microsoft use this convention and the library defines thousands of
constants in this fashion.

Maybe in c header files for Win32 constants, but not for
..Net, as far as I know.

From
http://www.irritatedvowel.com/Programming/Standards.aspx

"Same naming conventions as public/private member variables or
procedure variables of the same scope. If exposed publicly from a
class, use PascalCase. If private to a function/sub, use camelCase..

Do not use SCREAMING_CAPS

Why: This convention is consistent with the .NET Framework and is easy
to read. A sizable section of the Framework Design Guidelines is
dedicated to why they chose not to go the SCREAMING_CAPS route. Using
SCREAMING_CAPS also exposes more of the implementation than is
necessary. Why should a consumer need to know if you have an enum, or
(perhaps because they are strings) a class exposing public constants?
In the end, you often want to treat them the same way, and black-box
the implementation. This convention satisfies that criteria."

And here it is straight from the source:
http://blogs.msdn.com/brada/archive/2004/02/03/67024.aspx

"We used the term SCREAMING CAPS to indicate an all upper case style.
Luckily this style (and name) did not survive in the final guideline."

If you like SCREAMING CAPS, go ahead, but you are violating the
official guidelines, even if you think otherwise.

You will find a bunch of them in places like
System.Drawing.NativeMethods,
but that is because they were ported from Win32.

Can you point me to a place in the framework where I can find a large
collection of .Net-originated constants that use SCREAMING CAPS(?)

Regards,

Joergen Bech
 
Smokey Grindle,
The naming rules in FxCop is based on the "Design Guidelines for Class
Library Developers":

..NET 3.0
http://msdn2.microsoft.com/en-us/library/ms229042.aspx

..NET 2.0 (VS 2005)
http://msdn2.microsoft.com/en-us/library/ms229042(vs.80).aspx

..NET 1.x (VS 2003)
http://msdn2.microsoft.com/en-us/library/czefa0ke(vs.71).aspx

..NET 3.5 (VS 2008 aka Orcas)
http://msdn2.microsoft.com/en-us/library/ms229042(vs.90).aspx

Although I don't see a specific reference to Constant members, Public
Constants fall under the Public Members guidelines, which as the others have
pointed out are Pascal Case. In your case PasswordMaximumLength.
 
Back
Top