62 lines
2.8 KiB
Plaintext
62 lines
2.8 KiB
Plaintext
=== on 5 Feb 2015, 17:44:14 Michael Gumowski wrote:
|
|
As I am currently encountering difficulties implementing the rule, I think that expressly mentioning the names of the variables in the issue message does not worth the effort.
|
|
|
|
Indeed, gathering the names of the variables to build a the proposed message imply several problems:
|
|
|
|
* It is costly (and complex) in terms of operations to gather them, and does not provides a lot of information (the issue is already detected on the line, it should not be hard to locate the issue);
|
|
* Variables are not always present in expressions manipulating these methods, implying that multiple messages are possible (increasing complexity of the rule as well). As shown in the following code:
|
|
|
|
----
|
|
List<String> getList() {
|
|
return new ArrayList<String>();
|
|
}
|
|
|
|
Integer getIntegerValue() {
|
|
return Integer.valueOf(1);
|
|
}
|
|
|
|
void myMethod() {
|
|
if (getList().contains(getIntegerValue())) { // Noncompliant. Always false. <<-- What would be the message
|
|
getList().remove(getIntegerValue()); // Noncompliant. list.add(iger) doesn't compile, so this will always return false <<-- Same problem
|
|
}
|
|
}
|
|
----
|
|
|
|
I would like to change the message to the following proposition, which I think is much simpler without loosing its pertinence:
|
|
|
|
____{code}"[class]<[type]>" will not contain any "[ytype]"{code}____
|
|
|
|
For the previous examples we would then have the syme following message :
|
|
|
|
____"List<String>" will not contain any "Integer"____
|
|
|
|
|
|
|
|
=== on 5 Feb 2015, 18:40:55 Ann Campbell wrote:
|
|
\[~michael.gumowski] how about
|
|
|
|
* A "[class]<[type]>" cannot contain a "[ytype]".
|
|
* You cannot add a "[ytype]" to a "[class]<[type]>".
|
|
|
|
=== on 6 Feb 2015, 07:43:26 Michael Gumowski wrote:
|
|
I'll take your first proposition if it's ok for you!
|
|
|
|
=== on 16 Nov 2018, 20:02:03 Jens Bannmann wrote:
|
|
The first paragraph of the rule description ends in an incomplete sentence, and it is redundant with the second and third paragraphs. Is it a leftover from revising it, or is there some kind of rendering error here in Jira?
|
|
|
|
|
|
____A couple Collection methods can be called with arguments of an incorrect type, but doing so is pointless and likely the result of using the wrong argument. This rule will raise an issue
|
|
|
|
|
|
The java.util.Collection API is having methods accepting Object as parameter such as Collection.remove(Object o) or Collection.contains(Object o). When the effective type of the object provided to these methods is not consistent with the type declared on the Collection instantiation, those methods will always return false or null. This is most likely unintended and hide a design problem.
|
|
|
|
|
|
This rule raises an issue when the type of the argument of the following APIs is unrelated to the type used for the Collection declaration:
|
|
|
|
|
|
(...)____
|
|
|
|
=== on 16 Nov 2018, 22:09:59 Alexandre Gigleux wrote:
|
|
\[~bannmann] Fixed
|
|
|