rspec/rules/S2159/comments-and-links.adoc

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