I'm refactoring a library in C# and I found a lot of upper case constants:
INTERVAL, TIME, SECONDS.
I think this a kind of unnecessary, and personally I prefer declare everything with camel case. Exist some exactly definition about the better way?
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.
It's all up to the standards that your group/team chose when they defined their coding guidelines.
If everybody else uses ALL_UPPER_CASE, then you should fall in line.
Personally, I prefer to use upper case for constants just so I know what they are simply by looking at them.
This is all preference, but the upper case is I believe a throw back to #define because a const isn't a far cry from it as I understand.
More specifically, I believe the upper case const is just another delineation method where you see in a method something in all caps and you know it's a const, if it's camel case it's local, camel case with _ is member private, and pascal case is member public.
Though this is just one standard of consistencies which some prefer, it really is preferential, though I think the reason is as I said, just to make it obvious when you see all caps you know it's a const.
All-caps constants are a common convention…
…but a convention is just that, and is arbitrary. If you are writing code for yourself, there is no compelling reason not to choose your own. If you work with other developers, you must all agree on a naming convention.
If you are writing something that will be consumed by others outside your team, you might do well to stick to the most common and recognizable naming conventions to avoid confusion.
In the end, consistency is what counts.
Microsoft's recommendations make no mention of all-uppercase names. They do not explicitly specify a casing convention for constants, but they have one for enum values (PascalCase) and read-only static fields (also PascalCase). So according to Microsoft's guidelines, PascalCase is probably your best option.
The MSDN page on constants suggests that constants should be treat like static field members. In this case, the Captialization Conventions would suggest that PascalCasing is appropriate.
If your constant is part of a public API, I would recommend following this convention.
If the constant is just a private member, however, you can use any convention you wish. MSDN, in this case, actually has lower case constant members in the Constant help page, for example.
I generally use PascalCase for public constants and camelCase for private ones. The exception is when the constants are imported from an older C/C++ library or similar (such as those use alongside P/Invoke). - I keep them as they were written in the original library.