107 lines
2.7 KiB
Plaintext

include::../summary.adoc[]
== Why is this an issue?
include::../description.adoc[]
=== Exceptions
The rule does not raise an issue on statements containing only a semicolon (``++;++``).
== How to fix it
include::../how-to-fix.adoc[]
=== Code examples
==== Noncompliant code example
[source,javascript,diff-id=1,diff-type=noncompliant]
----
function getResult() {
let result = 42;
if (shouldBeZero()) {
result == 0; // Noncompliant: no side effect, was an assignment intended?
}
return result;
}
----
[source,javascript,diff-id=2,diff-type=noncompliant]
----
var msg = "Hello, "
"World!"; // Noncompliant; have we forgotten '+' operator on previous line?
----
==== Compliant solution
[source,javascript,diff-id=1,diff-type=compliant]
----
function getResult() {
let result = 42;
if (shouldBeZero()) {
result = 0; // Compliant
}
return result;
}
----
[source,javascript,diff-id=2,diff-type=compliant]
----
var msg = "Hello, " +
"World!"; // Compliant
----
include::../see.adoc[]
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
include::../message.adoc[]
'''
== Comments And Links
(visible only on this page)
=== on 4 Jun 2015, 12:22:30 Linda Martin wrote:
\[~fmallet] regarding the cases about _string_ and _equality operator_ do you think the rule shall raise issue on those specific case or would it be generalised to all _literals_ and _relational expressions_ ?
=== on 4 Jun 2015, 12:35:43 Freddy Mallet wrote:
For the time being I would limit the scope to those specific cases where this is really realistic to think about a developer doing such mistakes while coding.
=== on 4 Jun 2015, 12:39:29 Linda Martin wrote:
OK!
=== on 20 Aug 2015, 12:26:40 Elena Vilchik wrote:
I removed
----
function () {...} // Noncompliant; anonymous function declared, then lost
----
from the scope of this rule, as this is a syntax error.
=== on 20 Aug 2015, 14:55:35 Elena Vilchik wrote:
I removed
----
new MyObj(); // Noncompliant - the created instance is lost
----
from the scope of this rule, but keeping ConstructorFunctionsForSideEffects check in place.
This pattern produces a lot of FP. As this rule should track bugs only, we don't want have these FP.
=== on 21 Aug 2015, 08:47:39 Elena Vilchik wrote:
\[~ann.campbell.2] We discussed a lot this rule and decided to spread it on other cases (like identifier statement or number literal statement). Also we removed object creation from the scope of this rule. As now it differs a lot from RSPEC-2998 we decided to make RSPEC-3000 independent rule.
Could you check that this RSPEC is ok?
include::../comments-and-links.adoc[]
endif::env-github,rspecator-view[]