5 ms·

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a

by tjmehta 11y ago

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a bunch of reasons. DRY is the most obvious one, but one that may be less obvious is for better testing. I move out modules so I can write really nice tests for the independent of the projects I am using them in. Also, I tend to write projects w/ 100% test coverage, breaking out utils allows me to test projects easier and faster. Also note, the implementation of this module changed a few times today. With it being open source and having the collaboration of other engineers, we ended up with a very performant version, and discovered interesting quirks about "safe integers" in JS.

phaedryx 11y ago
With how weird javascript can be about numbers, it actually didn't surprise me that your module existed.
gizmo385 11y ago
"DRY is the most obvious one, but one that may be less obvious is for better testing." Isn't that why we just write functions? Turning simple functions into entire modules just adds an unnecessary level of abstraction that helps nobody.
- tedmiston 11y ago
  Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that. It's like (micro)crowdsourcing (the smallest components of) the standard library that JavaScript never had. Some bit of logic could go from being DRY in one project, to DRY in all of my projects, ... to eventually be DRY in all projects. It's globally DRY.
  - lolidaisuki 11y ago
    >Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that. Sounds an awful lot like a library.
deleted 11y ago
[deleted]
TickleSteve 11y ago
Two points: - Breaking out is-positive-integer hasn't reduced the number of paths to test. You have not gained anything, you've added overhead. - 100% test coverage is rarely a good thing. It is required for safety critical areas like avionics. I can guarantee that your JS code is not making into any safety critical environment!
- kristiandupont 11y ago
  >hasn't reduced the number of paths to test But it has: it's now tested, and you don't need to write tests for it next time you want to use it. >100% test coverage is rarely a good thing Not sure what your argument is here. Sure, it may not be helpful but are you saying that one should strive for less than 100% coverage, because "it's rarely good"?
  - mtreis86 11y ago
    100% coverage is rarely worth the time, unless it's an engine controller or something else that needs the assurances.
    - Confusion 11y ago
      If tjmehta likes to cover his open source code 100%, under whatever metric, by God let's encourage him in that and not start a discussion about the economic sense of it!
- serge2k 11y ago
  > 100% test coverage is rarely a good thing Do you mean rarely useful, or actively harmful?
  - TickleSteve 11y ago
    Both in a way. What happens when you have a "100% test coverage" requirement is that people don't think about the tests, they simply make tests to force the code down every path without thinking whether it was intended to operate like that. For example if the is-positive-integer had a silly test for "if(value==23) return false", a requirement for "100% test coverage" would simply result in someone creating a test for that condition instead of considering if it was actually a fault. 100% test coverage != no faults. What you have done by generating 100% test coverage is effectively 'frozen' your code and made it harder to implement any changes.
augustl 11y ago
That's interesting. JavaScript has enough quirks to warrant an is-positive-integer module.
- plugnburn 11y ago
  See: isPositive = (x) => +x === x && x > 0 In which conditions does it return a wrong value? I haven't found any.
nvader 11y ago
Just to pick at a nit with you, it's a little meaningless to say "100% test coverage", without specifying whether you're talking about line coverage, branch coverage, path coverage... This is especially true for one-liner modules in js, where any test at all might let you claim 100% statement coverage, without accounting for branches or loops within method calls.
Confusion 11y ago
It would be really, really great if this function was not in its own module, but was part of a larger library in which all such functions of related modules were captured, without the (cognitive and other) overhead of the separate packaging.
collyw 11y ago
Actually, thats a good reason to use trivial functions like the one described. Hopefully the author has discovered all of the quirks in Javascript that might affect this. It will likely be a lot more tested than any version I would write. As someone who spends 80% on the back end, I often get bit on the ass from JavaScripts quirks when I need to add some front end stuff.

by tjmehta 11y ago

phaedryx 11y ago

With how weird javascript can be about numbers, it actually didn't surprise me that your module existed.

gizmo385 11y ago

"DRY is the most obvious one, but one that may be less obvious is for better testing." Isn't that why we just write functions? Turning simple functions into entire modules just adds an unnecessary level of abstraction that helps nobody.

tedmiston 11y ago
Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that. It's like (micro)crowdsourcing (the smallest components of) the standard library that JavaScript never had. Some bit of logic could go from being DRY in one project, to DRY in all of my projects, ... to eventually be DRY in all projects. It's globally DRY.
- lolidaisuki 11y ago
  >Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that. Sounds an awful lot like a library.

deleted 11y ago

[deleted]

TickleSteve 11y ago

Two points: - Breaking out is-positive-integer hasn't reduced the number of paths to test. You have not gained anything, you've added overhead. - 100% test coverage is rarely a good thing. It is required for safety critical areas like avionics. I can guarantee that your JS code is not making into any safety critical environment!

kristiandupont 11y ago
>hasn't reduced the number of paths to test But it has: it's now tested, and you don't need to write tests for it next time you want to use it. >100% test coverage is rarely a good thing Not sure what your argument is here. Sure, it may not be helpful but are you saying that one should strive for less than 100% coverage, because "it's rarely good"?
- mtreis86 11y ago
  100% coverage is rarely worth the time, unless it's an engine controller or something else that needs the assurances.
  - Confusion 11y ago
    If tjmehta likes to cover his open source code 100%, under whatever metric, by God let's encourage him in that and not start a discussion about the economic sense of it!
serge2k 11y ago
> 100% test coverage is rarely a good thing Do you mean rarely useful, or actively harmful?
- TickleSteve 11y ago
  Both in a way. What happens when you have a "100% test coverage" requirement is that people don't think about the tests, they simply make tests to force the code down every path without thinking whether it was intended to operate like that. For example if the is-positive-integer had a silly test for "if(value==23) return false", a requirement for "100% test coverage" would simply result in someone creating a test for that condition instead of considering if it was actually a fault. 100% test coverage != no faults. What you have done by generating 100% test coverage is effectively 'frozen' your code and made it harder to implement any changes.

augustl 11y ago

That's interesting. JavaScript has enough quirks to warrant an is-positive-integer module.

plugnburn 11y ago
See: isPositive = (x) => +x === x && x > 0 In which conditions does it return a wrong value? I haven't found any.

nvader 11y ago

Just to pick at a nit with you, it's a little meaningless to say "100% test coverage", without specifying whether you're talking about line coverage, branch coverage, path coverage... This is especially true for one-liner modules in js, where any test at all might let you claim 100% statement coverage, without accounting for branches or loops within method calls.

Confusion 11y ago

It would be really, really great if this function was not in its own module, but was part of a larger library in which all such functions of related modules were captured, without the (cognitive and other) overhead of the separate packaging.

collyw 11y ago

Actually, thats a good reason to use trivial functions like the one described. Hopefully the author has discovered all of the quirks in Javascript that might affect this. It will likely be a lot more tested than any version I would write. As someone who spends 80% on the back end, I often get bit on the ass from JavaScripts quirks when I need to add some front end stuff.