In the application database there is a configuration table with this schema:

Table: ReleaseProperty

  1. ReleasePropertyID
  2. ReleaseID
  3. Name
  4. Value

Currently to retrieve a specific property I pass to the Repository class the arguments ReleaseID (that come from the current web page address) and a Name, that is basically hard coded


var property = ReleasePropertyRepository.Select(ReleaseID, "MyProperty");

I don't like to use hard coded strings around my code, and the only idea to improve the quality of this code is to use a container class for constants.

var property = ReleasePropertyRepository.Select(ReleaseID, Constants.MyProperty);

Is there any other way to develop a better code?


1 Answer 1


Hardcoded strings are not a problem. Let them be.

What you should have though is functions wrapping the queries so each of the identifiers is only used once in the code.

If you have more than one place where you need the strings, creating constants for them makes sense, because the compiler will make sure that they are consistent. But if you have one place in code and one place in the database, the compiler won't be checking anything if you make constants, so the only thing constants will give you is more lines of code, (probably) extra source where the constants will live and more places to change whenever the constants need to change (because you want to change both the value and the name of the constant every time; in this case you need to know the actual string, so letting the symbolic name and text diverge would make things worse). And they'll win you exactly nothing, because checking against the database (or configuration or whatever) will still only happen in tests and/or at runtime.

The usual advice against hard-coded values is about values where the meaning of the value is not obvious from the value and can be made obvious by introducing a symbolic constant or constants that appear in multiple places where have to be kept consistent. Meaning of keys in configuration or property table is obvious from the value and usually don't appear in many places, so the advice does not apply.

Or, more succinctly, if you have more descriptive name for the value, or if you can make the actual value strongly typed, make a symbolic constant. If the symbolic name would derive from the value, don't.

… you seem to have the later case.

  • 2
    The usual advice against hard-coded string values is that they're not strongly typed (but rather, are stringly-typed), and therefore the compiler cannot check them. Jul 21, 2014 at 15:44
  • @RobertHarvey: How do you create a non-string value for "MyProperty" and the like? Jul 21, 2014 at 16:37
  • @BartvanIngenSchenau: By making it a property on a class. Jul 21, 2014 at 16:37
  • @RobertHarvey: And what is exactly the advantage of a property (of type string) that is used only once over a string literal? Jul 21, 2014 at 16:41
  • @BartvanIngenSchenau: There might not be an advantage if it's only used once. Jul 21, 2014 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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