C# Constants Management Best Practices

Question

I'm a 22 yo dev and some days ago I looked out for the best practices to store and manage constants in a project. I found a guy on StackOverflow that said that you must create a static class with static methods that return the constant value, in that way you have all the constants inside one file and if you ever have to make a change you can easily find the constant... but I was thinking "If I want to be able to switch to debug constants or release constants without writing too much checks inside my code and have a strong consistency, how can I make it based on this 'best practice'?" so I wrote this, it works but i wanted to know from more expert dotnet and C# devs if it is a good way to do that or not:

public abstract class ConstantsBase 
{
    public static ConstantsBase Instance {get; set;}
    protected ConstantsBase() {}

    public abstract string GetSomeValue();
}

public class ConstantsA : ConstantsBase
{
    public override string GetSomeValue()
    {
        return "SomeValue";
    }
}

public class ConstantsB : ConstantsBase
{
    public override string GetSomeValue()
    {
        return "SomeOtherValue";
    }
}

public class Program 
{
    public static void Main()
    {
        #if DEBUG
        ConstantsBase.Instance = new ConstantsA();
        #elif RELEASE
        ConstantsBase.Instance = new ConstantsB();
        #endif

        Console.WriteLine(ConstantsBase.Instance.GetSomeValue());
    }
}

I designed it as a singleton so it can be called from anywhere inside the program without being instantiated more than one time.

Answer 1

Here are some suggestions for improvements on your basic idea, which is clever!

1. If your constants can change according to the environment, you might want to make them app settings rather than constants, But, I also note that app settings are usually also dependent on contants, for their keys, themselves!

2. Following on with that idea: if you have a lot of settings, and they vary by environment, you might want to make a settings class that you inject into the app, rather than a constants file. How you populate it can vary.

3. But if constants are really the best fit, I would rework the classes a little, to avoid even having singletons. You can use the same idea you have here, with the compiler directives, with static classes:

   So, a file called ConstantsDebug.cs :

    // Don't call it "ConstantsDebug": call it just "Constants", but // wrap _the whole thing_ in a `#if... #endif` #if DEBUG public static partial class Constants { public const string SomeValue = "SomeValue"; } #endif

   ... and the same for ConstantsRelease.cs :

    #if RELEASE public static partial class Constants { public const string SomeValue = "SomeOtherValue"; } #endif

4. If you wind up with a lot of environments and a lot of constants (or a lot of app settings keys) you might want to use T4 files, reading from a master list, to generate the code.

5. If your constants consistently fall into categories, you might want to specialize your files a little more. For example, if you use feature flagging, and have constants for the flag names, you could have a sub-class in a separate code file, that (logically) was within the constants class:

    public static partial class Constants { public static partial class FeatureFlags { public const string FeatureFlagOne = "FeatureFlagNameOne"; } }

This could then be invoked through referencing Constants.FeatureFlags.FeatureFlagOne .