Wait, endosquid writes tax software and expects that whenever a bit of data gets corrupted it should display an account balance of 0? Please share the name of this phenomenal software product.
Indeed, it's amazing that the same person could say "We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages" and "Each of those changes will have to be coded, tested, written-off, released, tested by the clients since this is tax data and has to be precise for tax planning and retirement planning."
They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.
Anyone who uses PHP seriously knows when accepting user input you have to do type checking rigorously. The manual states the input has to be a float. Of course in PHP this means it SHOULD be a float but why risk sending it a variable who's type is still undecided?
They probably only care about the presentation aspect of it, and not doing any calculations with uninitialized variables. The users are probably worried about showing NULLs instead of zeroes on empty fields.
alkavan's comment on this thread is dead, reposted here:
Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently.
It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
