views:

426

answers:

4

I keep a lot of settings in AppSettings, and I was wondering if it's considered good practice to name them in UpperCase. Essentially, they're the same as Constants right? As I understand it, if you change the Web.Config, the app does a recompile.

So, I was thinking, should you keep the settings in AppSettings in UPPERCASE (Assuming you name your constants with all UPPER case.)

Also, should variables that get values from AppSettings be UPPERCASE?

EG.

String MY_SETTING = ConfigurationManager.AppSettings["MY_SETTING"];

What is the best way to handle these and make them look and feel like Constants? Is it even a good idea? The only way I could think of would be make it readonly:

readonly String MY_SETTING = ConfigurationManager.AppSettings["MY_SETTING"];

But then I don't know how you could do this with an int:

readonly String MAX_USERS_S = ConfigurationManager.AppSettings["MAX_USERS"];
readonly int MAX_USERS; // needs to be set here... won't compile
int.TryParse(MAX_USERS_S, out MAX_USERS);

I somehow feel dirty setting readonly variables to look like constants, but to me, stuff in the web.config are essentially constant.

Suggestions?

+1  A: 

No. There is no cases of all-uppercase naming in the .NET naming guidelines.

Richard
Naming guidelines or not. Companies have naming guidelines too.
Atømix
If you have your own naming guidelines you can, of course, use them in preference to someone else's. But then I don't see the point of the question; noting that naming guidelines should be suited to the idioms of the tools in question.
Richard
+2  A: 

If you feel they're effectively constant, and they're readonly variables of an immutable type (int, string etc) then by all means use the same naming convention. Indeed, this is what String.Empty does. However, the .NET naming convention for constants isn't SHOUTY_CAPS, it's PascalCase.

Jon Skeet
Isn't the that same as Public variables, though?
Atømix
Yes - but the only public variables you should have are readonly immutable ones anyway, which is exactly the scenario you're describing.
Jon Skeet
(Readonly *static* immutable ones, sorry.)
Jon Skeet
Ah, SHOUTY CAPS, the official name for all things uppercase. :D I like it.
Jeff Yates
I dare say there's a more correct name for it, but I doubt it would convey my feelings about it as effectively ;)
Jon Skeet
+1  A: 

If you want them to look and feel like constants, the first place I would recommend is naming them with Pascal-case, so MY_SETTING (which isn't really a C#-like name) would be "MySetting". You see this a great deal with publicly exposed properties and constants in the framework.

readonly is the correct way to go here. In the case of an instance field, it can only be set in the declaration or the constructor. For static fields, it may only be set in the static constructor or declaration.

For the call to TryParse, you would set it in your constructor, or the static constructor, depending on whether or not it was an instance or static field:

static MyClass()
{
    // The value.
    int myUsers;

    // Try to parse.
    if (int.TryParse(MAX_USERS_S, out myUsers))
    {
        // Assign.
        MyUsers = myUsers;
    }
}
casperOne
+1  A: 

As I understand it, if you change the Web.Config, the app does a recompile.

That's correct, any change to the Web.Config will recompile the app. Even changes as small as a newline.


Ignoring the naming conventions question, you could do the following with your example:

readonly int MAX_USERS = 
    int.Parse(ConfigurationManager.AppSettings["MAX_USERS"])

Obviously this is not a safe way to do this in the event that MAX_USERS is not an int, but it seems that throwing an exception when MAX_USERS can't be set would be the correct course of action.

Gavin Miller
Good point. Actually, i believe the int.TryParse method just wraps the method around a Try Catch block. But still, but the idea of try/catch blocks everywhere makes me feel icky. :-)
Atømix