How reduce the usage of Magic Strings?

Question

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

Table: ReleaseProperty

ReleasePropertyID
ReleaseID
Name
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

E.g.

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?

Possible duplicate of [What is wrong with magic strings?](https://softwareengineering.stackexchange.com/questions/365339/what-is-wrong-with-magic-strings) — gnat, Jun 25 '18 at 12:49

Jan Hudec · Answer 1 · 2014-07-21T18:15:19.407

5

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.

edited Jul 21 '14 at 18:15

answered Jul 21 '14 at 15:23

Jan Hudec

18,250
1
39
62

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. – Robert Harvey Jul 21 '14 at 15:44
@RobertHarvey: How do you create a non-string value for `"MyProperty"` and the like? – Bart van Ingen Schenau Jul 21 '14 at 16:37
@BartvanIngenSchenau: By making it a property on a class. – Robert Harvey Jul 21 '14 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? – Bart van Ingen Schenau Jul 21 '14 at 16:41
@BartvanIngenSchenau: There might not be an advantage if it's only used once. – Robert Harvey Jul 21 '14 at 16:41
@RobertHarvey: Then I can't really place your initial comment. – Bart van Ingen Schenau Jul 21 '14 at 17:09
@RobertHarvey: And if you actually _read_ the answer and the question you'd have known that we are talking about case where the strings are each used only once. Which you yourself accepted is there might be no advantage of constants in. So this whole discussion is irrelevant to both the question and the answer. – Jan Hudec Jul 21 '14 at 18:13
Yeah, I don't really get what the OP is trying to do. As to the discussion, we could have stopped at my first comment. :) – Robert Harvey Jul 21 '14 at 18:14

How reduce the usage of Magic Strings?

1 Answers1