71 lines
2.8 KiB
Plaintext
71 lines
2.8 KiB
Plaintext
=== deprecates: S1294
|
|
|
|
=== deprecates: S1318
|
|
|
|
=== is related to: S5845
|
|
|
|
=== on 15 Oct 2014, 22:04:22 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 21 Oct 2014, 15:16:06 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 22 Oct 2014, 13:29:05 Ann Campbell wrote:
|
|
Let me know which cases you want to cover
|
|
|
|
=== on 22 Apr 2015, 16:36:44 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 22 Apr 2015, 16:42:23 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 23 Apr 2015, 15:39:06 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.
|
|
|