3 ms·

I don't know specifically in this case but usually you keep currency numbers in whole numbers and then divide by 100 when you need decimals. is a much cleaner m

I don't know specifically in this case but usually you keep currency numbers in whole numbers and then divide by 100 when you need decimals. is a much cleaner method then using bigints

golergka 6y ago
Your customer with 90 trillion dollars will not be happy about it (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). I have been bitten with this in production, although it was facebook id represented as number and not money amount. On a more realistic scenario, imagine that get 1% cashback on their purchases. When you multiply their purchase amount by 0.01, you get sub-cent amounts. From a point of view of a particular customer, it doesn't matter much, so you can just floor the number. But on the scale of your whole organisation, it does matter; so, where's all the remainder are going to end up at? And even if you don't forget about these remainders, are you sure you will remember to add the values before the division, as 10 or 20, and not after, as 0.1 or 0.2? Because when you some the latter up, you won't get 0.3. If you're just using a built-in 'number' type, you're facing these mistakes by yourself, but a well-written library for handling money will guard you against this. Types exist not only to represent values, but to guard you against doing such mistakes. (And if that's the first time ever you hear about this scenario, do yourself a favour and watch Office Space — which does not only include this scenario as a plot device, but is a terrific movie on it's own right). I have to be honest, I tend to forget all the details when I don't work with these kinds of tasks for some time. Instead, I just remember that using any standard built-in integer type for money is a huge potential minefield. And since in Javascript it's really a float, even more so.

I don't know specifically in this case but usually you keep currency numbers in whole numbers and then divide by 100 when you need decimals. is a much cleaner method then using bigints

golergka 6y ago

Your customer with 90 trillion dollars will not be happy about it (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). I have been bitten with this in production, although it was facebook id represented as number and not money amount. On a more realistic scenario, imagine that get 1% cashback on their purchases. When you multiply their purchase amount by 0.01, you get sub-cent amounts. From a point of view of a particular customer, it doesn't matter much, so you can just floor the number. But on the scale of your whole organisation, it does matter; so, where's all the remainder are going to end up at? And even if you don't forget about these remainders, are you sure you will remember to add the values before the division, as 10 or 20, and not after, as 0.1 or 0.2? Because when you some the latter up, you won't get 0.3. If you're just using a built-in 'number' type, you're facing these mistakes by yourself, but a well-written library for handling money will guard you against this. Types exist not only to represent values, but to guard you against doing such mistakes. (And if that's the first time ever you hear about this scenario, do yourself a favour and watch Office Space — which does not only include this scenario as a plot device, but is a terrific movie on it's own right). I have to be honest, I tend to forget all the details when I don't work with these kinds of tasks for some time. Instead, I just remember that using any standard built-in integer type for money is a huge potential minefield. And since in Javascript it's really a float, even more so.