71 lines
2.8 KiB
Plaintext
71 lines
2.8 KiB
Plaintext
|
=== Deprecate: RSPEC-1294
|
||
|
|
|
||
|
|
=== Deprecate: RSPEC-1318
|
||
|
|
|
||
|
|
=== Related: RSPEC-5845
|
||
|
|
|
||
|
|
=== On 2014-10-15T22:04:22Z Freddy Mallet Wrote:
|
||
|
|
My 2 cents:
|
||
|
|
|
||
|
|
* I would prefer the "Reliability" SQALE category because such kind of comparison can't be done on purpose
|
||
|
|
* Providing a compliant solution is valueless and can even be misleading
|
||
|
|
* I would extend the Noncompliant Code Example to provide an example for each kind silly equality checks
|
||
|
|
|
||
|
|
=== On 2014-10-21T15:16:06Z Nicolas Peru Wrote:
|
||
|
|
How would we detect cases such as :
|
||
|
|
|
||
|
|
|
||
|
|
----
|
||
|
|
Interface I {}
|
||
|
|
class A extends B implements I{}
|
||
|
|
class B {}
|
||
|
|
...
|
||
|
|
B b = new A();
|
||
|
|
I i;
|
||
|
|
b.equals(i); //On this call B and I have nothing in common in the class hierarchy, but this can return true.
|
||
|
|
----
|
||
|
|
|
||
|
|
=== On 2014-10-22T13:29:05Z Ann Campbell Wrote:
|
||
|
|
Let me know which cases you want to cover
|
||
|
|
|
||
|
|
=== On 2015-04-22T16:36:44Z Samuel Mercier Wrote:
|
||
|
|
\[~ann.campbell.2] As a first step I will implement the following:
|
||
|
|
|
||
|
|
|
||
|
|
EC: equals() used to compare array and non-array (EC_ARRAY_AND_NONARRAY)
|
||
|
|
|
||
|
|
----
|
||
|
|
Object[] array = ...;
|
||
|
|
MyObject object = ...;
|
||
|
|
array.equals(object); // Always false
|
||
|
|
object.equals(array); // Could return true, but following specification of equals this should always return false (different message to prevent misleading ?)
|
||
|
|
-> 'contract of 'equals' requires false as return value when the passed argument has type 'array''
|
||
|
|
----
|
||
|
|
|
||
|
|
EC: equals(...) used to compare incompatible arrays (EC_INCOMPATIBLE_ARRAY_COMPARE)
|
||
|
|
|
||
|
|
----
|
||
|
|
Object[] objects = ...;
|
||
|
|
String[] strings = ...;
|
||
|
|
objects.equals(strings); // Always false: message should probably suggest usage of java.util.Arrays.equals(Object[], Object[]) to compare contents
|
||
|
|
----
|
||
|
|
EC: Call to equals(null) (EC_NULL_ARG)
|
||
|
|
|
||
|
|
----
|
||
|
|
Object object = ...;
|
||
|
|
object.equals(null); // could return true, but following specification of equals this should always return false
|
||
|
|
-> 'contract of 'equals' requires false as return value when null is passed as argument
|
||
|
|
----
|
||
|
|
|
||
|
|
=== On 2015-04-22T16:42:23Z Samuel Mercier Wrote:
|
||
|
|
\[~ann.campbell.2] As stated by Nico it is easy to build examples which generate false positives.
|
||
|
|
|
||
|
|
|
||
|
|
For this reason I think EC_UNRELATED_CLASS_AND_INTERFACE, EC_UNRELATED_INTERFACES and EC_UNRELATED_TYPES should not be covered by this RSPEC, because the message and description would be misleading.
|
||
|
|
|
||
|
|
=== On 2015-04-23T15:39:06Z Ann Campbell Wrote:
|
||
|
|
Per our discussion, I've left EC_UNRELATED_CLASS_AND_INTERFACE, EC_UNRELATED_INTERFACES and EC_UNRELATED_TYPES in this RSpec since, as you pointed out [~samuel.mercier] EC_ARRAY_AND_NONARRAY, EC_INCOMPATIBLE_ARRAY_COMPARE are more specific examples of the general cases - i.e. it would eventually be confusing for users to have this as 2 separate rules.
|
||
|
|
|
||
|
|
Note that the FB description indicates that the FB check includes an examination of the relevant ``++equals++`` methods and limits issue raising to when the comparison will always return false or not be symmetric.
|
||
|
|
|