Design Advice on Getter or Const for String in Classes - what are others doing?

Question

I am seeking some advice on what is the recommend way to use 'constant' strings within my classes, e.g.

public string EmployeesString { get { return "Employees";  } }

const string EmployeeString = "Employee";

The reason I would like to implement these, i.e. either via a const or via a getter, is because throughout my class(es), I have methods and constructors that use these strings as parameters and I was thinking to avoid typos and also to avoid using strings (weakly-typed?), I wanted to reference them strongly, e.g.

DoSomething(this.EmployeeString, employee);

What are others doings? Any advice will be greatly appreciated! Is this good/bad?

Answer 1

The "right" answer, in my opinion, depends on how and why you're using the string.

If the string is being used for display, or presented to a user, then the property is a better design. This makes it much easier to add localization later by moving the constant into resource files, without having to change your API. This also makes it easier to adapt your class without breaking other code, since you are free to change the "constant" at any time without breaking other assemblies.

I rarely find appropriate uses for the second case - very few strings are truly constant, and when they are, I believe they're typically better represented as an enumeration instead of a string. This is almost always better than "magic strings" in your code.

The rare exceptions are typically when interacting with legacy code - if you're dealing with a separate API that is expecting a string, and the string is truly constant, than using a constant is potentially "better", in that it is more efficient and very clear in its intent.

Also, remember that the two approaches can be used together:

private const string employeeString = "Employee";

public string EmployeeString { get { return employeeString; } }

This allows you to use the constant, making it's intent clear, but easily change this out later without breaking other code or changing your API. (I personally prefer this to your "second" option above, since the magic string in the property getter is a code smell to me - I like my constants to be obvious constants, but still prefer properties.)

Answer 2

Any strings that you will be using for display or UI work should be put into resource files. This allows for a strongly typed key, but it also allows for easy internationalization of your application, as you can get the resource file translated to a new language and it will be automatically applied for users of that culture.

For example, if you put a new .resx file into your project called "ApplicationStrings", and added a key/value pair of "EmployeeString"/"Employee" to it, you could call it in your application like this:

DoSomething(ApplicationStrings.EmployeeString, employee);

If you created a translated version of these strings, let's say for Mexican Spanish, you would just create a new file called ApplicationStrings.es-mx.resx. When people with the es-mx culture setting used your program, it would automatically use the translated version!

So the advantages are pretty clear - strongly referenced values, easy localization, and centralized management of magic strings in your application.

Even for strings that won't end up being displayed, I usually create resource files for them anyway, like "InternalStrings.resx". This way you can use strongly typed references to internal "magic strings" that your program might need, and if you need to change them, you only have to change the value in one place.