views:

165

answers:

4

which one is good:

string sQuery = "SELECT * FROM table";

or

const string sQuery = "SELECT * FROM table";

And why resharper always suggest me to do this?

+1  A: 

ReSharper only suggests this if the particular string reference never changes. In that case you express your intend by using const string instead of just string.

Brian Rasmussen
+6  A: 

The latter is better - it means that:

  • This isn't an instance variable, so you don't end up with a redundant string reference in every instance that you create
  • You won't be able to change the variable (which you presumably don't want to)

There are some other effects of "const" in terms of access from other assemblies and versioning, but it looks like this is a private field so it shouldn't be an issue. You can mostly think of it as being:

static readonly string sQuery = ...;

In general I believe it's a good idea to make fields static when you can (if it doesn't vary by instance, why should it be an instance variable?) and read-only when you can (mutable data is harder to reason about). Let me know if you want me to go into the details of the differences between static readonly and const.

Jon Skeet
please go on to explain their differences. (Thank you from now)
uzay95
And what do you think const/readonly using in functions?
uzay95
http://stackoverflow.com/questions/410723/is-there-a-difference-between-private-const-and-private-readonly-variables-in-c might shed some light
Patrick McDonald
also http://stackoverflow.com/questions/55984/what-is-the-difference-between-const-and-readonly
Patrick McDonald
+1  A: 

It does this because if you accidentally assign a new value to sQuery in your code, if it's a const you'll get a compile error, so it will catch a bug at compile time. Same with its suggestion to make member variables which are set in the ctor only to be readonly

Frans Bouma
+2  A: 

If the string never changes and is never used outside your assembly, then const is a good idea. If it never changes but is used outside your assembly, static readonly might be a better idea -- consts are "burned in" at the site of the call, not stored in one location, so recompiling the assembly that contains the const does not update the dependent assemblies -- they have to be recompiled too. static readonly variables on the other hand do get updated in dependent assemblies.

Rytmis
" outside your assembly, static readonly might be a better idea "Why? <br/>Even they want to change "static sQuery" or "static readonly sQuery" nothing will be changed. ? .
uzay95
Readonly ensures you don't try to reassign to it, and static variables are still variables (unlike consts), so if you change the string in the assembly where it's defined, the updates propagate to the dependent assemblies. This doesn't happen when you change a const, unless you recompile the dependent assemblies too.
Rytmis
Note that if it's a local variable instead of a field, this is not applicable. :)
Rytmis

related questions