Question: I was often wondering about the right way to do this:

For example, in my program I have around 100 constants (or enums) that are used in some calculation. They should preferrably be stored in one place. They can be grouped hierarchically, for example:

```
System3 / Rules / Rule7 / ParameterXY / MaxAverageValue

```

Naturally, I want those values to be accessible while coding, so storing them in some kind of ressource is not really an option.

As far as I could tell, this can be done with:

* very long constant names
* nesting classes
* namespaces

Using names is quite ugly, and it's not really well maintainable. I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way. Lastly, I find the suggested alternative, using namespaces, not terribly nice neither. Imho it creates masses of folders and files that each contain almost nothing. And I don't like when 50 sub-namespaces pop up in the assembly reflector.

So.. how do you do this kind of task? What would you suggest?

Answer: 
> 
> very long constant names
> 
> 
> 

This is sort of gross, but at least it is discoverable. All your code would reside in the same place so you wouldn't have a problem finding it.

> 
> I find nesting classes a nice way to do it, but some stylecop/fxcop rules forbid that, so this must be "bad" in some way
> 
> 
> 

One reason it is is bad because automated code generation/code inspection tools are harder to work with. Another reason is that it is harder to discover these with Intellisense.

The most important reason this is bad is because a nested class should be strongly associated in an object-oriented dependency sense for the layout be make sense logically. In all but some rare cases (e.g. [Enumerator classes](http://msdn.microsoft.com/en-us/library/x854yt9s.aspx)) it won't make sense. In your case it also doesn't make sense because your classes don't really have any behavior or object orientation at all - they're just a hierarchy of constants.

> 
> Namespaces
> 
> 
> 

For the problem you described, this is the best way to handle it. You get the least clutter per-level, and you get Intellisense while typing so you can see what you're narrowing down to while descending through the hierarchy.

> 
> Imho it creates masses of folders and files that each contain almost nothing
> 
> 
> 

If you really need a huge pool of constants, and it doesn't make sense to bind them to other parts of your application, then this is one of the rare cases that I'd abuse the one-file-per-class and one-folder-per-namespace rules. The only reason you're even stuffing them into classes at all is because .Net doesn't have support for global variables.

**Another suggestion**

Do you have domain-specific objects that these constants belong on instead? E.g. is there any logic related to the `System3 / Rules / Rule7` class? Is that not some sort of actual business rule that you should embody with its own class?

If you can arrange your code so that you have [a thicker domain model](http://en.wikipedia.org/wiki/Anemic_domain_model), then the most logical place to put your constants is on the classes that embody the corresponding domain logic.

If it doesn't make sense to have a thick domain, you have fully generic rules processing, and you are relying on constants to feed your business engine logic, then you have a data-driven application. This means you should store your data in configuration files, not in code.
Well the way I do this is to have a sealed file called Constants.

so 

```
public sealed class Constants
{

  //for e.g.
  //Sessions
  public const string APPSESSIONKEY = "AppType";

}

```

Than I use this in the rest of my project and the importance here is what you will name it as it will help you remember it and make sense when you need it.

By calling it in your code.

```
Constants.AppSessionKey

```

You could also 

Create an Assembly whose only purpose is to hold constant values for the project. Every other Assembly should then reference this one. Following DRY and KISS, since adding references is simple enough. Main problem here is recompilation.