4 ms·
Considering that's 25 year old code I'd expect at least a #define VAT 0.25 and not hardcoded values all around the source code. However I don't expect a tab
by pmontra 1y ago
Considering that's 25 year old code I'd expect at least a
#define VAT 0.25
and not hardcoded values all around the source code. However I don't expect a table (db table, array, etc) of product categories with their own VAT code or a user defined exception list. That extra code would inevitably add bugs that are not worth the trouble. Adding an exception for books probably requires an update of the apps.
- deleted 1y ago[deleted]
- bruce511 1y agoVAT is not a compile-time value. It's a runtime value. Nevermind not scattering it in your code, it shouldn't be in your code at all.
- Ekaros 1y agoVAT rate can and does change. As such it can be different on different dates. And this change might not even correspond to change of year. So it really has no place in code.
- tossandthrow 1y agoThe US is used to this as the rate changes between states and product categories - it is not reasonable to adopt this view onto other VAT systems. You can not transfer categorical statements like you do.
- kqr 1y agoSuch a constant would be no better -- they don't want to change the VAT rate across all product types. The code missing is that for per-product type variation in VAT rate, which sounds complicated enough that Iawould expect a good engineer to shrug and say YAGNI until it's actually necessary.