34 lines
1.9 KiB
Plaintext
34 lines
1.9 KiB
Plaintext
=== relates to: S899
|
|
|
|
=== supercedes: S1154
|
|
|
|
=== on 24 Nov 2014, 12:57:37 Nicolas Peru wrote:
|
|
This rule seems ok to me but the message is not convincing me. I would go for something more explicit about the fact that the return value of the method is ignored.
|
|
|
|
"Return value of method 'xxx' is not used"
|
|
|
|
=== on 1 Dec 2014, 09:31:20 Freddy Mallet wrote:
|
|
And we should be careful to not mix this rule with RSPEC-899:
|
|
|
|
* RSPEC-899 is about ignoring the result of a function call when this result indicates the status of the operation: KO, OK (so when exceptions are not used to trigger issues)
|
|
* This one RSPEC-2201, is about ignoring the result of a function call when this result contains the output of the operation
|
|
|
|
=== on 27 Mar 2015, 13:36:47 Ann Campbell wrote:
|
|
Per discussion, I floated closing RSPEC-899 to C-Family team & met with objections.
|
|
|
|
=== on 10 Jan 2016, 12:46:52 Freddy Mallet wrote:
|
|
Hi [~ann.campbell.2], I don't understand why this rule is not part of "Sonar way" quality profile because for sure when an issue is raised this is bug.
|
|
|
|
=== on 11 Jan 2016, 18:15:09 Ann Campbell wrote:
|
|
As I recall [~freddy.mallet], it's a question of confidence in accurately identifying methods without side effects.
|
|
|
|
=== on 13 Jan 2016, 09:26:38 Freddy Mallet wrote:
|
|
I know [~ann.campbell.2], but for instance in Java we've tuned the rule to be sure at 100% that we're not generating any false-positives (by limiting the scope to calls to immutable objects) and I think we must do the same thing for the other targeted languages. So at least in Java, this rule must be activated by default (cc [~nicolas.peru]).
|
|
|
|
=== on 13 Jan 2016, 13:33:55 Ann Campbell wrote:
|
|
Done [~freddy.mallet]
|
|
|
|
=== on 21 Feb 2020, 14:59:38 James Bromwell wrote:
|
|
I created https://github.com/SonarSource/SonarJS/issues/1948[a new issue on the SonarJS GitHub tracker] but I'm not sure if the fault is in the rule itself or in the JS/TS implementation of the rule, so I thought it might be worth bringing up here.
|
|
|