Ad
  • Custom User Avatar

    As for the applied notation, it was built with the aim of simulating a real environment. Where we need to maintain the standardization of a legacy system.

    Floats can create big problems, so it's in our docs to avoid them whenever possible, regardless of your rationale about a legacy system, which wasn't stated in the description. If you must simulate a legacy environment, I strongly suggest finding another angle to do it on that won't cause difficulties in translation and unpredictably failing assertions.

    Staying away from floating-point values is usually a good way to solve problems related to ... monetary values (dollars and cents)

    See:

  • Custom User Avatar

    Thanks for the contribution. I used the template provided by codewars, I was surprised by the bug with assert, but I already applied the suggested fix.

    As for the applied notation, it was built with the aim of simulating a real environment. Where we need to maintain the standardization of a legacy system.

  • Custom User Avatar

    Thanks for the contribution. I included random tests

  • Custom User Avatar
  • Custom User Avatar

    A few issues:

    • The provided test says assert isn't defined. After importing it, diffs print poorly due to truncation. I suggest adding:
      const {assert, config} = require("chai");
      config.truncateThreshold = 0;
      
    • Discounts stored as strings and prices stored as floats seem unusual. These practices coupled with the unstated rounding requirement push the solution to resort to awkward/artificial formatting. I'd store everything as an integer to avoid floating point misbehavior, especially if this is ever translated to non-JS languages.
    • I can't do const newPrice = ... because newPrice is inexplicably defined in the preloaded. I'd suggest removing this.
    • Rather than "new-price", I'd suggest a camel cased key: "newPrice", which is more idiomatic for JS, allowing natural dot notation access.