If I have a method that receives a value as parameter and stores it in a field for later usage, but then goes on to use that value - why would I use the parameter instead of the field?private RailState _railState;public void UseParameter(RailState railState){    _railState = railState;    railState.SetActive();}public void UseField(RailState railState){    _railState = railState;    _railState.SetActive();}As far as i can see, an argument for using a parameter is that if the class would be changed later and the value would only be used in that method, a decent IDE would inform me that the field is never read from and thus unnecessary.An argument for using the field is that using the parameter won't work for value types. While this is obvious and intuitive for basic types like numbers, it might lead to surprises with unexpected structs.However, are there other arguments - one way or the other - that I am missing?
After assigning a parameter to a field, use the parameter or the field?
c#;parameters
As you pointed out, the field approach work well in all the cases (value and reference). This should be the preferred approach.Another reason speaking in favour of the field is refactoring: if your method grows to be very complex, you could more easily split in in simpler methods when using the field approach.The  parameter could however be a better approach when handling unique operations related to the initialisation, especially in a multithreaded application, where the field could be altered by another method invoked in another thread.Hypothetical example: _railstate = railstate;  railstate.incrementUseCount(1); // because use count of parameter is to be increased _railstate.activate(); // may be another thread already changed the field and decrementer use count of former field ?So rather than dogmatism, I'd recommend to really think of the semantic: do we want to address the parameter regardless of the object state ? Or do we intend to address the object corresponding to the object state (e.g.referred by the field) ?