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 1

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) 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, 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.