Keeping constant strings

N a v a n e e t h

I am looking for a good method to keep my constants. Currently I have created a static class like this

public static class ConstantMessages
{
public static string ServerCommunicationFailure = "Message";
public static string AuthenticationFailure = "Message";
}

I have many fields like this. Is this a good approach ? Or is there any alternative better approach for this ? I will be using the above class like the following

try
{
// Doing something that communicates with remote server
}
catch(Exception ex)
{
throw new CommunicationException(ConstantMessages.ServerCommunicationFailure);
}

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

Christian Graus

I'd just use a settings class, that's what they are for. But, this does work just fine.

Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )

N a v a n e e t h

Christian Graus wrote:

But, this does work just fine.

Thanks. Yes this works fine, but it tough to maintain. Each time a variable and it's value has to be added. Settings class looks good, I will give a try. There is going to be many settings which will be kept in this settings file, do you think it will slow down the accessing ?

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

Kalvin Work

Looking at this example it looks like there is a contradiction of ideas here. The class is called ConstantMessages, but the strings inside the class are being set up so that the application can modify them. If you want constant messages why not use: public const string ServerCommunicationFailure = "Message"; This should give a performance benefit. If I am wrong, someone please correct me so I can continue to learn. Kalvin

N a v a n e e t h

Yes you are correct. I wrote that to explain the problem. This is not used exactly as it is.

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

PIEBALDconsult

Use an enum with Description attributes?

enum Messages
{
[Description("Message")]
ServerCommunicationFailure
,
[Description("Message")]
AuthenticationFailure
}

Roger Alsing 0

However, the recomended way by MS is to use static readonly instead of const. because of versioning issues. if you use a const, every consumer that use your const will have the const value compiled down into the consumer code. while if you access a readonly field, the consumer code will always get the values from the owner class. in short, if you use consts and then ship a new version of the dll containing your consts, those changes will not affect already compiled code. while if you use readonly fields, it will affect already compiled consumers..

My Blog

N a v a n e e t h

Very valid points. Thanks for that Roger

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

N a v a n e e t h

Thanks. I will take a look into that.

All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

PIEBALDconsult

What?! :omg: I've never seen that documented anywhere. But I just tried it and it seems to be true. That doesn't make sense. Edit: It's true of enum members as well. I just looked through the specs and saw no mention of this functionality, but I see now that it does make (some) sense. Among other things, const values are valid in case labels, and case labels must be unique. Changing a const value (or enum) could make a previously-compiled switch invalid. So, yeah, I think a best practice is; unless the value is an actual constant value like Pi, don't use public const, but use public readonly instead. Using private const, may not be as bad, but the next developer to come along may make your privates public. So use const sparingly. Thanks for the tip.

modified on Monday, May 12, 2008 11:46 AM