I have various constants that my program uses... string
's, int
's,double
's, etc... What is the best way to store them? I don't think I want an Enum
, because the data is not all the same type, and I want to manually set each value. Should I just store them all in an empty class? Or is there a better way?

- 55,572
- 24
- 139
- 212

- 28,056
- 26
- 104
- 170
-
24Any way you want it -that's the way you need it. – San Jacinto Nov 12 '09 at 18:02
9 Answers
You probably could have them in a static class, with static read-only properties.
public static class Routes
{
public static string SignUp => "signup";
}

- 3,982
- 2
- 25
- 42

- 187,200
- 47
- 362
- 445
-
1
-
25+1, but even better if you can pull these from a resource file for localization. – Joel Coehoorn Nov 12 '09 at 17:46
-
19
-
2
-
2This sounds good. Like emptyset said, is there any reason to use properties here instead of static readonly strings? – Matthew Nov 12 '09 at 17:59
-
9Why readonly and not const? You are not setting the value at runtime, so there is no need to have them as readonly. – Philip Wallace Nov 12 '09 at 18:01
-
2
-
104The problem with const is that any assemblies compiled against consts get local copies of those consts when they themselves are compiled; so if you change a value you must also recompile all assemblies dependent on your assembly defining the constants - therefore its often safer to go the readonly route. Properties instead of public static values gives you flexibility to add some programming logic in the future if you need it (i.e. read from localization) without changing the interface to your constant values. – cfeduke Nov 12 '09 at 18:24
-
18As the devil's advocate I must point out that the advantage with const is that you can use it in switch cases. – arviman Dec 15 '13 at 09:10
-
4I personally went the constants route but declared the class that contains them to be internal so they can't be used outside the assembly and eliminating the problem of them not getting updated in other assemblies. Of course, that doesn't help if you do need them outside the assembly. It does give me some peace of mind that someone else can't use them outside the assembly without explicitly changing the class modifier. – Jeff Jan 31 '14 at 21:54
-
1@arviman And you can only use constant values in attributes, no readonly will do there. – Alex Feb 02 '15 at 08:39
-
just adding that static readonly fields can ben changed by reflection and so might be a security issue. see https://stackoverflow.com/questions/12201063/setting-readonly-fields-is-this-bug – Jonathan Nappee Sep 28 '15 at 15:37
-
You can't use these "constants" in a switch statement. See other ansers for a better solution. – Gerard Aug 03 '16 at 09:51
-
But I cannot use these constants in switch case.. What's the solution for it? – Praburaj Dec 29 '16 at 09:16
IMO using a class full of constants is fine for constants. If they will change semi-occasionally I recommend using AppSettings in your config and the ConfigurationManager class instead.
When I have "constants" that are actually pulled in from AppSettings or similar I still will always have a "constants" class that wraps the reading from configuration manager. It's always more meaningful to have Constants.SomeModule.Setting
instead of having to resort directly to ConfigurationManager.AppSettings["SomeModule/Setting"]
on any place that wants to consume said setting value.
Bonus points for this setup, since SomeModule
would likely be a nested class inside the Constants file, you could easily use Dependency Injection to inject either SomeModule
directly into classes that depend on it. You could also even extract an interface on top of SomeModule
and then create a depenedency to ISomeModuleConfiguration
in your consuming code, this would then allow you to decouple the dependency to the Constants files, and even potentially make testing easier, especially if these settings come from AppSettings and you change them using config transformations because the settings are environment specific.

- 32,487
- 24
- 164
- 258
-
1Just to add to this: the reason is that when you build, constants used from other assemblies are not updated. This means that if you have AssemblyA and AssemblyB and B uses a constant from A, the value is copied, not referenced, so re-building A won't update B. This can lead to weird bugs. – Camilo Martin Mar 28 '12 at 19:27
-
1@CamiloMartin lots of ways to handle that, your "constants" could just static readonlys to avoid that, or as I said if they change more than once in a blue moon to use the ConfigurationManager. – Chris Marisic Mar 29 '12 at 12:46
-
Yes, I was just saying that it's not just because it's a convention that you should use static readonly, but because it actually can be a source of confusion. Also, an alternative to ConfigurationManager is resource files - you just have to add another resource file with a language code in the name and your code is instantly localized. – Camilo Martin Mar 29 '12 at 19:56
-
the problem is that when you reference this assembly from other assemblies, you would have to copy the values into their config files – symbiont Sep 10 '16 at 11:12
-
@symbiont you could embed the config files and read them out of the manifest instead if you wanted, for sharability as a 3rd party component – Chris Marisic Sep 16 '16 at 19:59
What I like to do is the following (but make sure to read to the end to use the proper type of constants):
internal static class ColumnKeys
{
internal const string Date = "Date";
internal const string Value = "Value";
...
}
Read this to know why const
might not be what you want. Possible type of constants are:
const
fields. Do not use across assemblies (public
orprotected
) if value might change in future because the value will be hardcoded at compile-time in those other assemblies. If you change the value, the old value will be used by the other assemblies until they are re-compiled.static readonly
fieldsstatic
property withoutset

- 4,610
- 2
- 31
- 54
-
1
-
Why does static readonly work better with multiple assemblies than const? – Matthew Nov 12 '09 at 18:06
-
17Const values are copied from the source assembly into the compiled code. This means if you have to change a const value, all dependent assemblies MUST be recompiled against the new version. Safer and more convenient to use static readonly's. – cfeduke Nov 12 '09 at 18:26
-
7
This is the best way IMO. No need for properties, or readonly:
public static class Constants
{
public const string SomeConstant = "Some value";
}

- 7,905
- 3
- 28
- 40
-
10If you are going to use const, expose as internal only. Do not make const public (even if you think your assemblies aren't going to be used external to your organization). Also properties give you programmatic flexibility for future expansion without the need to redefine your interface. – cfeduke Nov 12 '09 at 18:28
-
1It's ok and good to use `const` for things that really are unchanging (such as mathematical constants). Use `readonly` when the the property or value may change between different versions of the program. – AlainD Jan 18 '21 at 11:10
An empty static class is appropriate. Consider using several classes, so that you end up with good groups of related constants, and not one giant Globals.cs file.
Additionally, for some int constants, consider the notation:
[Flags]
enum Foo
{
}
As this allows for treating the values like flags.

- 3,164
- 4
- 26
- 33
-
"Consider using several classes, so that you end up with good groups of related constants, and not one giant Globals.cs file." I believe this is the best recommendation, aren't there some design patterns around this? I do not know any by name, do you? – greg Mar 15 '17 at 23:47
Another vote for using web.config or app.config. The config files are a good place for constants like connection strings, etc. I prefer not to have to look at the source to view or modify these types of things. A static class which reads these constants from a .config file might be a good compromise, as it will let your application access these resources as though they were defined in code, but still give you the flexibility of having them in an easily viewable/editable space.

- 28,657
- 18
- 88
- 151
-
2A connection string isn't a constant, it's a setting. It could be that the OP *really* means settings too, rather than constants, but I don't see any evidence for it. – Jon Skeet Nov 12 '09 at 17:49
-
I beg to differ. String literals are constants by definition. Changing the string in a config file is roughly equivalent to changing it in code and recompiling; would *that* make it not a constant? I don't think so. – 3Dave Nov 12 '09 at 18:25
-
2@David - Not true. A compiler doesn't care about what value you have in your config file - this is read at runtime. – Philip Wallace Nov 12 '09 at 21:06
-
@PhilipW I understand that. My point was that (in response to Jon Skeet's comment) a specific connection string is a constant, as all string literals are. The fact that a "constant" can be changed - be that by modifying the config file, and having your app pull the new value from said config file, or by changing the literal in code which would require a recompile/deploy - doesn't make it a "setting." The string itself is constant regardless of its container. I understand and agree with your point - it just wasn't what I was saying. – 3Dave Nov 13 '09 at 01:57
-
2In my experience, at some point in the unforeseen future, your "constant" value will need to change even if you thought it would never in a million years. I think this is much easier to do in a .config file than changing the source code. Everything ends up being a setting in the end. – NinjaBomb Jul 27 '10 at 21:05
-
Absolutely. I think the confusion here is that we're attempting to differentiate between "constant" and "setting", which isn't as useful a distinction as it would have been in the past. – 3Dave Jul 27 '10 at 21:48
I would suggest static class with static readonly. Please find the code snippet below:
public static class CachedKeysManager
{
public static readonly string DistributorList = "distributorList";
}

- 609
- 7
- 4
If these Constants are service references or switches that effect the application behavior I would set them up as Application user settings. That way if they need to be changed you do not have to recompile and you can still reference them through the static properties class.
Properties.Settings.Default.ServiceRef

- 1,031
- 10
- 23
Yes, a static class
for storing constants would be just fine, except for constants that are related to specific types.

- 47,767
- 15
- 98
- 117
-
that's exactly what i'm trying to do. i want them to show up as members of the class they are for. but i don't want to add them to the classes because the constants vary depending on the company i'm doing the work for. i haven't found anything yet about extension constants or properties. but i might abandon this idea because i don't want them to show up as members when i serialize these classes – symbiont Sep 10 '16 at 11:18