10

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?

uzay95
  • 16,052
  • 31
  • 116
  • 182

4 Answers4

21

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
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • please go on to explain their differences. (Thank you from now) – uzay95 May 26 '09 at 09:12
  • http://stackoverflow.com/questions/410723/is-there-a-difference-between-private-const-and-private-readonly-variables-in-c might shed some light – Patrick McDonald May 26 '09 at 09:29
  • also http://stackoverflow.com/questions/55984/what-is-the-difference-between-const-and-readonly – Patrick McDonald May 26 '09 at 09:30
  • I have a similar question, but specifically about local method variables/consts: http://stackoverflow.com/questions/5833912/advantages-of-using-const-instead-of-local-variables – M4N Apr 29 '11 at 15:54
  • I guess I was wrong to follow the advice that suggested to use "const" only for natural (maybe not just natural, but which have very minimal chance of changing) constants; like const int numberOfDaysInAWeek = 7, const string firstDayOfTheWeek = "Sunday" etc, was I? If the accepted answer for this post, http://stackoverflow.com/questions/555534/when-if-ever-should-we-use-const, is correct, then how can Resharper decide whether the value of the variable would change or not in the future? Would it not be safer to not make that suggestion? – haku May 27 '15 at 12:00
4

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
  • 31,467
  • 8
  • 60
  • 69
  • " outside your assembly, static readonly might be a better idea " Why?
    Even they want to change "static sQuery" or "static readonly sQuery" nothing will be changed. ? .     – uzay95 May 26 '09 at 09:20
  • 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 May 26 '09 at 09:22
  • 1
    Note that if it's a local variable instead of a field, this is not applicable. :) – Rytmis May 26 '09 at 09:23
1

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
  • 114,645
  • 34
  • 221
  • 317
1

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
  • 8,259
  • 1
  • 27
  • 28