Why does resharper suggests using readonly in fields that are not changed?

Question

to clarify the question, I'd like to add that I'm not asking why I should choose readonly over const or what are the benefits of readonly over const.

I'm asking why to make a field readonly just because it's not changed (at the moment).

for example: if I'd write the following class:

public class MyClass
{
      public int _i = 5;

      // Code that doesn't change the value of i:
      ...
}

Resharper will indicate that it can be made readonly.

Thanks

Answer 1

When it detects that you are not assigning to a variable except at initilization, it presumes that you don't want the variable to change. Making the variable readonly (or const) will prevent you from assigning to the variable in the future. Since this seems (by usage) to be the behavior you want, it makes the suggestion that you formalize it and derive the benefit of the protection.

Answer 2

I usually try to remember ¹ to do what Resharper's trying to remind you to do. If I have any fields that are immutable, I like to mark them with readonly to formalize that. On many types, I do this will all the fields. There are benefits of immutability ( [2] [3] ), and Resharper is trying to help you take advantage of them.

_{¹ I personally don't use Resharper. I have my reasons.}

Answer 3

Well, it's pretty obvious, that a variable that's never changed should be either const or read-only. The question which one of these is better depends on the situation. Const variables are by definition constant - their values should NEVER change (eg const int minutesInAnHour = 60; looks like a good candidate). That's why the constant is a static member implicitly and it is initialized during compile time, ie the compiler might actually replace all the appearances of your constant with the literal value, though I'm not sure if any compiler actually does that.

Readonly, on the other hand, is a member variable whose value should not change, once initialized, meaning that it is not actually a constant, you can do something in the lines of readonly DateTime time = DateTime.Now; . This, of course, will not be a static member, in fact it will be a normal member just with the restriction that it can't be changed once assigned. The benefit of this vs. const is that if your const variable changes in some build, other dependad libraries may not know that - they can even have the constant value comppiled in - you'll have to rebuild everything.

And as for the question why resharper suggests readonly vs. const - I'm not sure, I'd guess that a readonly variable is less restrictive and it figures that that's what the developer probably wanted.

Answer 4

Resharper is a tool, it can not see anything but the code you show it. If you plan to change the code in the future Resharper has no way of knowing -- so it makes suggestions based on your current code.

Answer 5

Resharper will indicate that it can be made readonly.

To add to other answers, note that you can change the severity of this inspection in ReSharper | Options | Code Inspection | Inspection Severity | Field can be made readonly . I have it as 'Show as suggestion'; you can ask ReSharper to ignore this inspection entirely, if you want.

Answer 6

When we use readonly and const in one compiled dll (let's call it 'source dll') which is used by another compiled dll (let's call it client's dll), then when we change const in source dll, we have to compile not only the source dll but also the client's dll, because const is set during compiling time. In turn, readonly is set during program's runtime, so when we change this value in source dll, then we have to only compile source dll, without compiling client's dll. I think this is one of the reasons that Resharper suggests readonly - because when it's changed, it will require less work. The second reason is, I think, what Saulius Valatka wrote, that const should be real 'constant' value, as for example 60 minutes in an hour and not value which seems to be constant, but eventually will change. So there are fewer real 'constant' values, than those which we think that will be 'constant', but eventually they change.