Property vs Field Usage
It would be nice if R#er can detect the inconsistent usage of property and field. I found that in many occasions, developers sometimes use properties sometimes use fields to refer to the same thing in the same class. It sometimes causes bugs which are hard to find. Plus it would be nice to detect the usage of property inside property block which may cause recursion i.e.
public int Count {
get { return Count; }
set { Count = value; }
}
Please sign in to leave a comment.
Hello Nat,
what usages of properties and fields do you consider inconsistent? In my
opinion,
it is not easy to work out a strict and clear policy of what should be used
in what situation.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
like in the same class... I have the code in one place saying that
count = 3;
while in the other place, I have the code saying that
Count = 3;
usually both of them should behave the same way but when someone starts to put logic in property definition i.e. do some lazy initialization, that's when the code starts to break.
OK, I see, but on the other side it is quite possible that in some
places the field is intentionally used instead of the property - to avoid
executing
that very additional logic of the property. Imagine that I would like to
know how often the
property is called, so I put a counter into the property. Some methods of
the same class may
be considered 'clients' and they call property while others reference the
field to avoid counting.
It's not possible to decide which references should be where without knowing
what the class author
had in mind when defining the property.
But I agree that the tool could detect inconsitent usages of fields and properties
in simple cases such
as when the property does not include additional logic.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry Shaporenkov (JetBrains) wrote:
>> like in the same class... I have the code in one place saying that
>>
>> count = 3;
>>
>> while in the other place, I have the code saying that
>>
>> Count = 3;
>>
>> usually both of them should behave the same way but when someone
>> starts to put logic in property definition i.e. do some lazy
>> initialization, that's when the code starts to break.
>>
Hi Dmitry,
But still, the property recursion is detectable... Also if
field/property declarations do not correspond to the property name and
coding style.
I've had many occasions that I refactored a property name to something
else, but leaving the fieldname intact...
// endless recursion warning:
public string ServerName{
get{ return ServerName; }
}
// inconsistent property/field naming warnings:
public string ServerName{
get{ return server; }
}
public string ServerName{
get{ return FServerName; }
}
Thanks,
Wiebe
Hello Wiebe,
yes, may be it is a good idea to catch this simplest kind of property recursion
- I remember
myself coming accross this bug a couple of times. Could you please submit
a request to
the tracker?
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> OK, I see, but on the other side it is quite possible that in some
>> places the field is intentionally used instead of the property - to
>> avoid executing
>> that very additional logic of the property. Imagine that I would like
>> to
>> know how often the
>> property is called, so I put a counter into the property. Some
>> methods
>> of the same class may
>> be considered 'clients' and they call property while others reference
>> the field to avoid counting. It's not possible to decide which
>> references should be where without knowing what the class author
>> had in mind when defining the property.
>> But I agree that the tool could detect inconsitent usages of fields
>> and
>> properties in simple cases such
>> as when the property does not include additional logic.
>> Regards,
>> Dmitry Shaporenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>> like in the same class... I have the code in one place saying that
>>>
>>> count = 3;
>>>
>>> while in the other place, I have the code saying that
>>>
>>> Count = 3;
>>>
>>> usually both of them should behave the same way but when someone
>>> starts to put logic in property definition i.e. do some lazy
>>> initialization, that's when the code starts to break.
>>>
Submitted...
http://www.intellij.net/tracker/resharper/viewSCR?publicId=10873
Thanks...
Wiebe
Dmitry Shaporenkov (JetBrains) wrote:
>> Dmitry Shaporenkov (JetBrains) wrote:
>>
>>> OK, I see, but on the other side it is quite possible that in some
>>> places the field is intentionally used instead of the property - to
>>> avoid executing
>>> that very additional logic of the property. Imagine that I would like
>>> to
>>> know how often the
>>> property is called, so I put a counter into the property. Some
>>> methods
>>> of the same class may
>>> be considered 'clients' and they call property while others reference
>>> the field to avoid counting. It's not possible to decide which
>>> references should be where without knowing what the class author
>>> had in mind when defining the property.
>>> But I agree that the tool could detect inconsitent usages of fields
>>> and
>>> properties in simple cases such
>>> as when the property does not include additional logic.
>>> Regards,
>>> Dmitry Shaporenkov
>>> JetBrains, Inc
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"
>>>
>>>> like in the same class... I have the code in one place saying that
>>>>
>>>> count = 3;
>>>>
>>>> while in the other place, I have the code saying that
>>>>
>>>> Count = 3;
>>>>
>>>> usually both of them should behave the same way but when someone
>>>> starts to put logic in property definition i.e. do some lazy
>>>> initialization, that's when the code starts to break.
>>>>
>> Hi Dmitry,
>>
>> But still, the property recursion is detectable... Also if
>> field/property declarations do not correspond to the property name and
>> coding style.
>>
>> I've had many occasions that I refactored a property name to something
>> else, but leaving the fieldname intact...
>>
>> // endless recursion warning:
>> public string ServerName{
>> get{ return ServerName; }
>> }
>> // inconsistent property/field naming warnings:
>> public string ServerName{
>> get{ return server; }
>> }
>> public string ServerName{
>> get{ return FServerName; }
>> }
>> Thanks,
>>
>> Wiebe
>>