Hacker News new | ask | show | jobs
by fifilura 902 days ago
Huh? Did you miss the modulo operator?
3 comments

It is not just modulo, it also test for whether the input is a number or integer. It also has one dependency, is-number. And isOdd(“3”) returns true.

Basically it helps dealing with all the typing problems of Javascript, and also fitting into functional programming paradigms.

If you need to know if a number is even or odd then you should convert it to an int natively anyway.
Given the lack of integers and my hesitancy to trust modulo for non-integer variables, I don't know if I would trust it. You would need to add some safety checks, but either you create an is_even/is_odd function that has safety checks, or you have to rely on developers adding in the checks anytime the number might have been in close proximity to a floating point number.

Something as simple as this can end up being neither even or odd.

    (0.1 + 0.2) * 10
It wouldn't have 200k downloads a week unless there was a large number of programmers who didn't know how to do it.

I mean we're talking FizzBuzz secret sauce here. This must be total black magic for a catastrophic percentage of programmers

I have not read the source but I had always assumed that this was the lovingly crafted effort of someone who is intimately familiar with the js standard making sure that some hypothetical expression like ![1] is neither odd nor even. Surely the idea that modulo is beyond developers is too horrifying to contemplate.
Here you go:

    /*!
     * is-odd <https://github.com/jonschlinkert/is-odd>
     *
     * Copyright (c) 2015-2017, Jon Schlinkert.
     * Released under the MIT License.
     */
    
    'use strict';
    
    const isNumber = require('is-number');
    
    module.exports = function isOdd(value) {
      const n = Math.abs(value);
      if (!isNumber(n)) {
        throw new TypeError('expected a number');
      }
      if (!Number.isInteger(n)) {
        throw new Error('expected an integer');
      }
      if (!Number.isSafeInteger(n)) {
        throw new Error('value exceeds maximum safe integer');
      }
      return (n % 2) === 1;
    };
It does some checking the `value` is an integer in the safe range, which doesn't even seem right to me. Why shouldn't you be able to call this on integers outside the save range?
(10e15 + 1) % 2 === 0
All non-safe integers are even, yes?
Sad but true. For JavaScript these kind of functions can actually be useful because of all the quirks. If that was the GPs hint then I can understand.
A more catastrophic number of programmers a) dont know how dependencies work and b) think everyone else are idiots.
Perhaps, I solidly understand how dependencies work and in this case my observation is defensible

Someone made the decision to use that and someone thought using stuff made by a person's who makes those kinds of decisions was a good idea and so on.

You can git blame dependencies all the way down and research the parties involved. I've done it, built tools for it even.

A stack of people who make bad decisions doesn't make good software.

More likely the author made another, more useful, package that uses it.