Posted by tony on 12/21/05 11:41

>> If it ain't broke, don't fix it

> Again, where have you been in the last 20 years? If a statement does not
appear to be executed because it "silences" any error condition, you
have a hell of a time finding bugs. PHP code can be very hard to read
because of its un-strictness. When I see a parameter initialised as
FALSE, I assume it is a boolean. I mean, the initialization is also
documentation. You see the parameters in your editor wherever you use
them. But it may be an array, a string, or whatever. But FALSE will not

break the code. You can write monstrous code that coincidentally works
with the parameter types you pass. Now code that is illegible is not
legible by your collegue either, *SO IT IS BROKE*. And, *YES, IT NEEDS
TO BE FIXED*.

You are missing the point. I'm talking about the situation where a
developer looks at an existing function which works in thousands (if
not millions) of scripts, and decides that the code is not elegant or
clean enough for his taste, so he decides to refactor it, but this
refactoring then breaks a lot of scripts. The argument that the code is
now *cleaner* or *purer* is irrelevant to the customers - all they know
is that previously valid scripts do not work any more. They do not care
if the code is clean or dirty, just that it keeps on working as
expected.

[Back to original message]