== Why is this an issue?

In JavaScript, some ``++Array++`` methods do not mutate the existing array that the method was called on, but instead return a new array. Other methods mutate the array, and their return value differs depending on the method.

``++reverse++`` and ``++sort++`` are mutating methods and, in addition, return the altered version. This rule raises an issue when the return values of these methods are assigned, which could lead maintainers to overlook the fact that the original array has been modified.

[source,javascript,diff-id=1,diff-type=noncompliant]
----
const reversed = a.reverse(); // Noncompliant: mutating method, no need to assign return value
const sorted = b.sort(); // Noncompliant: mutating method, no need to assign return value
----

Remove the assignment, so that the intent of mutating the original array is clear.

[source,javascript,diff-id=1,diff-type=compliant]
----
a.reverse();
b.sort();
----

Or use non-mutating alternatives ``toReversed`` and ``toSorted``.

[source,javascript,diff-id=1,diff-type=compliant]
----
const reversed = a.toReversed();
const sorted = b.toSorted();
----

Alternatively, change a mutating method into a non-mutating alternative using the spread syntax (`...`). 

[source,javascript,diff-id=1,diff-type=compliant]
----
const reversed = [...a].reverse();  
const sorted = [...b].sort();
----

Or `slice()` to create a copy first.

[source,javascript,diff-id=1,diff-type=compliant]
----
const reversed = a.slice().reverse();  
const sorted = b.slice().sort();
----

== Resources

=== Documentation

* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#copying_methods_and_mutating_methods[Array copying methods and mutating methods]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reverse[Array.prototype.reverse()]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort[Array.prototype.sort()]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed[Array.prototype.toReversed()]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted[Array.prototype.toSorted()]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax[Spread syntax (``++...++``)]
* MDN web docs - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice[Array.prototype.slice()]

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Move this array "{0}" operation to a separate statement.


=== Highlighting

``++x.reverse()++``


'''
== Comments And Links
(visible only on this page)

=== on 28 Jul 2017, 14:20:42 Elena Vilchik wrote:
I've put the rule back to Sonar Way as we removed more code-smelly case ``++a = a.reverse();++`` from the scope (moved to RSPEC-1656).   

=== on 16 Jan 2020, 10:23:52 Tibor Blenessy wrote:
Changed to code smell, we can't be sure that the code has a bug, and from issues we find it seems that more often it's not the case

=== on 14 Mar 2021, 11:23:01 JounQin wrote:
Hi, I tried this in SonarJS, it seems `items?.sort()` reports while `items.sort()` does not which is unexpected.


What means this rule is not compatible with `optional chaining`.

=== on 15 Mar 2021, 16:56:59 Tibor Blenessy wrote:
\[~JounQin] I created issue from your report \https://github.com/SonarSource/SonarJS/issues/2513 , however please use our community forum in the future \https://community.sonarsource.com/ ,  this JIRA project should not be used to report specific implementation issues, as it is agnostic about the language.

endif::env-github,rspecator-view[]
