const string field vs "typed" string

Question

i have a little function that goes like this:

void Bar(string s)
{
*/ do somthing with the string here.*/
}

void Foo()
{
    Bar("Hello");
}

if i look at the IL output, it gives me the following:

.method private hidebysig instance void Foo() cil managed
{
    .maxstack 8
    L_0000: ldarg.0 
    L_0001: ldstr "Hello"
    L_0006: call instance void TestApp.MainWindow::Bar(string)
    L_000b: ret 
}

now i thought i'd replace it with a const string field for it.

const string str= "Hello";
void Foo()
{
    Bar(str);
}

that translates TO THE EXACT SAME IL snippet.

now my question is which one to use?

Foo("Hello"); or Foo(cHello);

Thank you for your help!

--------------EDIT-------------------
To be more specific, i use this for Logging purposes to add a prefix to a message: AND it would only appear once in code!

so it looks more like this:

void LogDebug(string msg)
{
    Log("[DEBUG]", msg)
}
void Log(string pre, string msg)
{
    // generates an output in form of
    // pre + msg
}

:)

Answer 1

The answer should be obvious: since the IL is the same, use whatever works best based on purely source-code considerations.

In general, this means going with the const string in order to not have a magic value appear in your Foo method. If the constant is used just once this might not sound very convincing, but if there is even a possibility of using it more than once in the future then DRY is pretty much a shotgun argument.

Update:

In this specific case (debugging output, constant is guaranteed to be used only once) I don't think that a constant provides any value. I 'd hardcode the string literal.

Answer 2

const get replaced at compile time in the code. Its better if you use the const string instead of hard coded string since it makes them easy to maintain.

Answer 3

(1) Use const string for private or internal code if it would make the code more readable or you would have the same string more than once.

(2) DO NOT PUBLICLY EXPOSE CONSTS. Use properties instead. (Particularly with regard to strings.)

The reason for that is it tightly binds the const into the assemblies that reference it.

See here for more discussion about that point:

https://softwareengineering.stackexchange.com/questions/132747/is-having-public-constants-bad