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 smells "Hungarian". What do you think?
views:
6039answers:
7
+1
A:
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.
dove
2008-10-28 08:19:47
In this specific case it is *the* answer. But only because I love to read D.Adams so much.
Treb
2008-10-28 08:22:51
yes, but what's the question? and don't feed me that sorry for the inconvenience line ;)
dove
2008-10-28 08:26:07
Ah, but since you already know the answer, you cannot know the question. They are mutually exclusive. (Bet you already knew that ;-)
Treb
2008-10-28 08:28:33
A:
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.
John
2008-10-28 08:21:11
+5
A:
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.
Treb
2008-10-28 08:21:42
Code is read much more often than it is written. Sure, when you're writing the code the compiler will prevent you from assigning to a constant. But what about the guy who has to maintain your code two years from now? It's sure nice to be able to recognise a constant immediately.
Greg Hewgill
2008-10-28 08:26:08
Good point, Greg. Will have to think about this some more before changing...
Treb
2008-10-28 08:27:22
The IDEs of today catch a lot of problems before compilation. I don't think recognizing constant by name is important, otherwise shouldn't you add some special name for readonly variables as well?
mmiika
2008-10-28 08:34:16
If you think about it, the uppercase habbit probably came from preprocessor macros rather than constants (I've never used block caps for true constants). In that context, it makes sense to distinguish the macros from the actual code because a macro may well actually be an expression and not a constant value, its expansion may cause side effects and so on. So you need to know when you're using a macro and when you're using a const. I'm personally glad to see the back of preprocessor macros, they had a lot of potential to make code hard to read.
Tim Long
2009-05-09 05:38:12
@Tim: I agree, in the end preprocessor macros brought more harm than good. My most favourite PP macro: "#DEFINE Private Public" ;-)
Treb
2009-05-09 11:44:46
+12
A:
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.
bh213
2008-10-28 08:23:12
+39
A:
The recommended naming and capitalization convention is to use Pascal casing 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;
Greg Beech
2008-10-28 08:25:35
Actually, StyleCop is "not a Microsoft product," but "a tool developed by a very passionate developer at Microsoft (on evenings and weekends)." (See http://blogs.msdn.com/sourceanalysis/archive/2008/07/20/clearing-up-confusion.aspx and http://blogs.msdn.com/bharry/archive/2008/07/19/clearing-up-confusion.aspx) for details.) That being said, the Microsoft's framework naming conventions use Pascal casing for constants, so the tool is just enforcing the standard that Microsoft _does_ publish and endorse.
bdukes
2009-11-23 21:36:16
@bdukes - I didn't say it was a Microsoft product, however it does have quite a lot of usage and support throughout the organisation (as a former employee, I was using it years before anybody outside Microsoft got their hands on it, so I'm well aware of its heritage).
Greg Beech
2009-11-23 23:36:09
Worth noting that you can easily switch StyleCop rules off and do so in a way thats flexible across files, projects and solutions. In theory you can add your own rules too. In theory (-:
Murph
2010-02-03 11:24:19
+2
A:
I actually tend to prefer PascalCase here - but out of habit, I'm guilty of UPPER_CASE...
Marc Gravell
2008-10-28 08:27:45
+3
A:
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.