As soon as I published the sum() function, using reduce() and the rest parameter to sum any array of numbers a user may pass in, I shared the link at my mentor's Slack.

Incidentally, Chris Ferdinandi's Slack can be joined at the Vanilla JS Guides. Purchasing the guides gives you access.

As I'd expect, a fellow mentee there called to my attention what might be a performance issue. He pointed out that in the following function:

    var sum = (...args) => {
        var isNotANumber = el => typeof el !== 'number'
        if (args.some(isNotANumber)) return "Please enter only numeric numbers."
        return args.reduce((acc, cur) => acc + cur)
    }

I was running two loops - some() and reduce() where one might do and that bugged him.

Yeah, I introduced the some() array method since I needed a way to filter out any number that might be passed in and not fit the numeric type that can be mathematically summed. As you might know, this array method...

tests whether at least one element in the array passes the test implemented by the provided function.

In my case, isNotANumber() is the "provided function". It checks whether something matches the numeric type number or not, and returns either true or false. So, some() has to loop first, filter the array, before handing over to reduce().

In a small test case, this may not matter. And I don't know how it might be a big problem in a real world large-scale application. But my mentor's a performance nut who would stop at nothing to fix one when he finds it.

He did offer to rewrite my function.

Here's Chris' rewrite:

    var sum = function () {
        return Array.prototype.reduce.call(arguments, function (total, current) {

            // If the current item isn't a number, skip it
            if (typeof current !== 'number') {
                console.warn('"' + current + '" was skipped because it is not a number.');
                return total;
            }

            // Otherwise, add it
            total += current;
            return total;

        }, 0);
    };

I, myself, am insistent on brevity, conciseness, and more modern but predictable style of "javascripting". I...

  1. wanted to stick with the ...args rest parameter as that was in my original title,
  2. wanted the entire thing to keep the reduce() signature syntax very much you could see it at a glance, so
  3. had to rewrite Chris' rewrite...

Here's what I got:

    var sum = (...args) => {
        return args.reduce((acc, cur) => {
            if (typeof cur !== 'number') {
                console.warn(`
                    "${cur.toUpperCase()}" was skipped since it's not numeric. Summing will proceed without it.
                `)
                return acc
            }
            return acc + cur
        }, 0)
    }

Comparing with our orignal sum(), I even love how we've brought back best practice here and introduced an initial value, the 0 to reduce(). See?

Our sum() function proceeds as expected after skipping a non-numeric occurrence...

Finally, we got ourselves a summer function that is battle-tested. Yet, if some hotter-head programmer still has a bone to pick with it, I'm more than happy to revise - because peace and happy javacripting.