2

Is there a canonical way to differentiate between pure and impure / in-place functions in javascript? The first thing that comes to mind is prepending do, but is there a better / more standard way?

function double(A) {
    return A.map(x => x*2)
}
function doDouble(A) {
    for (var i = 0; i < A.length; i++) {
        A[i] *= 2
    }
    return A // Keep this for dot chaining
}
// other options: double_, doubleInPlace, doubleIP, double$, doubleμ...

There's no such practice in the standard library which is why resources like doesitmutate are necessary, but I'd like the reader of my library to avoid having to reference docs to check this.

Luke Miles
  • 941
  • 9
  • 19
  • [Naming convention for functions which have side effects?](https://softwareengineering.stackexchange.com/questions/332764) – adiga Jun 05 '21 at 07:10
  • Just an idea,. how about `refDouble`.. ref standing for reference double. Of course in JS arrays / objects are referenced implicitly, but I feel this just rolls of the tongue better than `mutateDouble`. Disclaimer, idea comes from VB with it's byRef keyword.. :) – Keith Jun 05 '21 at 07:22
  • This distinction shouldn't be encoded in names but should be type related. For instance, you should always assume that an array is mutated at some point, b/c it is a µtable data type. Vector on the other hand, is an imµtable one, because it is a persistent data structure (at least in clojure). Sure, you can use `Array.prototype.concat`, but it is a rediculously inefficient operation, which might be just enough for some tiny UI arrays but is not suitable for lager non-deterministic computations on Node.js. –  Jun 05 '21 at 08:36
  • 2
    I generally restrict my impure code to async functions. Hence, promises represent both asynchronous computations as well as impure computations, similar to the IO monad in Haskell. It works excellently because you can use pure computations in async functions but you can't directly use async computations in regular functions. – Aadit M Shah Jun 06 '21 at 02:01

1 Answers1

2

There is no naming convention in JavaScript to differentiate between pure functions and functions with side-effects.

It doesn't mean you shouldn't have one for your project though. I think it is a good idea.

A possible first approach is following the command–query separation principle, that states that only pure functions (queries) return values, while functions with side-effects (commands) do not.

Then you can look at existing languages following a similar convention.

In Scheme and Ruby (inspired by Scheme) functions causing side-effects end in ! (e.g. set-car!) and predicates end in ? (e.g. number?).

From https://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_3.html#SEC14:

By convention, the names of procedures that always return a boolean value usually end in "`?'". Such procedures are called predicates.

By convention, the names of procedures that store values into previously allocated locations (see section Storage model) usually end in "`!'". Such procedures are called mutation procedures. By convention, the value returned by a mutation procedure is unspecified.

Unfortunately you can't use ! and ? as part of a function name in JavaScript.

In Common Lisp, predicates end in p (e.g. EVENP) and destructive functions start with n (that stands for non-consing), e.g. REVERSE vs NREVERSE. While possible and compact, I don't find this particularly appealing.

Some languages use imperative and past verbs. Think about python's sort (in-place) vs sorted (functional).

Swift's API Design Guidelines is explicit about it:

Name functions and methods according to their side-effects

Those without side-effects should read as noun phrases, e.g. x.distance(to: y), i.successor().

Those with side-effects should read as imperative verb phrases, e.g., print(x), x.sort(), x.append(y).

Name Mutating/nonmutating method pairs consistently. A mutating method will often have a nonmutating variant with similar semantics, but that returns a new value rather than updating an instance in-place.

When the operation is naturally described by a verb, use the verb’s imperative for the mutating method and apply the “ed” or “ing” suffix to name its nonmutating counterpart.

Mutating: x.sort()

Nonmutating: z = x.sorted()

Mutating: x.append(y)

Nonmutating: z = x.appending(y)

Prefer to name the nonmutating variant using the verb’s past participle (usually appending “ed”):

/// Reverses `self` in-place. mutating func reverse()

/// Returns a reversed copy of `self`.
func reversed() -> Self
...
x.reverse()
let y = x.reversed()

When adding “ed” is not grammatical because the verb has a direct object, name the nonmutating variant using the verb’s present participle, by appending “ing.”

/// Strips all the newlines from `self`
mutating func stripNewlines()

/// Returns a copy of `self` with all the newlines stripped.
func strippingNewlines() -> String
...
s.stripNewlines()
let oneLine = t.strippingNewlines()

When the operation is naturally described by a noun, use the noun for the nonmutating method and apply the “form” prefix to name its mutating counterpart.

Nonmutating: x = y.union(z)

Mutating: y.formUnion(z)

Nonmutating: j = c.successor(i) Mutating: c.formSuccessor(&i)

All in all, any reasonable convention that fits your library will do, as long as it is applied consistently.

Domenico De Felice
  • 465
  • 3
  • 11