Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I often fight with myself on whether to put certain keys in my web.config or in a Constants.cs class or something like this.

For example if I wanted to store application specific keys for whatever the case may be..I could store it and grab it from my web config via custom keys or consume it by referencing a constant in my constants class.

When would you want to use Constants over config keys?

This question really applies to any language I think.

share|improve this question

6 Answers 6

Personally I would only use constants as default values, and let them be overridden by values from a configuration file.

If the application takes command line arguments, then those would in turn override the configuration file parameters.

share|improve this answer
    
this is a great approach –  Thanos Papathanasiou Nov 23 '11 at 11:31

Value in configuration file is harder to maintain than value in constants class, because the compiler does not check it exists and is of correct type, the IDE usually does not provide code assistance for it and also because it's yet another syntax you have to switch to while programming.

So I would suggest putting:

  • Values that will be the same in all installations as constants in code. There are some advantages to putting them in one constants class (you can easily try out various values to see how they work) and putting them in the module that uses them (you don't have to open yet another file when modifying that module and avoiding one file that everybody would edit causing conflicts in version control).
  • Values that (may) need to be changed per installation to config file. And you probably want to put default in the code anyway, so if the value is not set in the config, the application still (somehow) works.
share|improve this answer
    
what do you mean correct type...config keys...it's xml... –  CoffeeAddict Nov 23 '11 at 7:22
    
@CoffeeAddict: Correct type means, that if you have option that requires a number and your config file has non-numeric string in the place, you won't find until runtime. And "config key" is whatever you use to retrieve the value from config file, in case of XML the element path. Ok, you can have a schema and corresponding class (there is xsd tool to generate one from the other) and use the config with XMLSerializer (most sensible way to handle XML in C# anyway), so you can validate in advance, but it's still some extra work. –  Jan Hudec Nov 23 '11 at 8:10

Changing Constants require re-building the application most of the cases. Put other way, constants remains constants when someone doesn't have an access to code.

So any information that end user need to provide (and need to change) should go in the configuration files. Most others need to go under constants. However, there must be legitimate defaults or error exception handling if the configuration files are broken.

Elements which are not part of the abstraction of the object (i.e if constants which are not meant to be modified by external (calling) objects are likely to be hidden and essentially mean they would be better off as private constants than config files.

When there are many config elements which pertains to different objects, not related to each other, and when so many objects needs to pull out (same or their own) config files, chances are that these things should have been constants.

share|improve this answer

A simple rule of thumb is to create constants when you know you'll work with a fixed set of values which you know can be applied for any given context without needing to change; provide external configurations for everything else.

A good example of constants would be if all the shapes you worked with could either be SQUARE or ROUND. In most languages, you'll be able to leverage the fact that this value doesn't change over time, by allocating it only once and optimizing how it's accessed.

External configurations are necessary when you'll need to retrieve the value dynamically because you cannot assume in advance the value you'll be working with, but that doesn't mean you have to make any performance tradeoff: for configuration values you expect to be present, when done correctly, you only pay the price of retrieving them once and still get all the benefits.

share|improve this answer

You can also simply use this design pattern: "convention over configuration".

http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

share|improve this answer

A constant by definition is a memory location for a value that should not change (such as PI).

I assume you meant 'parameter' and not a constant

In addition to what have been said, note that exposing variables to user input from config file may harm the application.

When possible, don't expose values in config file without validating them in code to have a sanity check. Also, I suggest that you don't place business rules parameters (such as max. salary, etc.) in config files and don't use constants for those either. Such values should be stored in database with the appropriate table definitions so that some security is enforced when they are changed and you could automatically create versions of the data values (using stored procs or db logs). Of course, this depends on how sensitive your application is.

If you ever use config files to store data, make sure you version them.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.