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; }
}

6 comments
Comment actions Permalink

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!"

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; }
}



0
Comment actions Permalink

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.

0
Comment actions Permalink

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.



0
Comment actions Permalink

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

0
Comment actions Permalink

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!"

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



0
Comment actions Permalink

Submitted...

http://www.intellij.net/tracker/resharper/viewSCR?publicId=10873

Thanks...

Wiebe

Dmitry Shaporenkov (JetBrains) wrote:

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!"

>> 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
>>


0

Please sign in to leave a comment.