It's my opinion that bad input should be checked at the boundaries of a
system. I've always been blamed when my software responds improperly to
the bad inputs of my users. So, I've made a habit of validity checking
all input parameters to deflect the fickle finger of fate away from me.
At least in a debug build. I agree that after data gets in, repeatedly
checking it for validity is silly for the reasons Mel enumerated.
There's another consideration. The longer an error persists before it is
fixed, the greater the cost to fix it. If I accept a bad input, and get
into the middle of using it, it obscures the source of badness. Or if I
build something on top of badness, i'll have to clear away all the
accretions before I can get to the root cause.
This principle of cost-of-fix increasing monotonically with time scales
to every level of software development.
Martinez, Mel - 1004 - MITLL wrote:
I would offer a caution here. Validation of data needs to consider the
whole system.
No validation is an obvious problem. Bad data --> bad results.
But redundant validation is also a problem for a few reasons.
Redundant validation happens when data flows through a system and gets
validated for correctness at multiple points. Not only is this vulnerable
to inconsistent validation rules but also a potential performance drain.
Suppose a piece of data gets inserted into the system, applied to a setter
and validated before entry into a dictionary. Then later gets copied from
that same dictionary with a getter and then applied to another setter,
perhaps on another object - do we validate it again?
The general rule of thumb is to validate as close to the source of input as
possible so that the corrective responses are most appropriate / contextual
with the way the data is input.
So this is not a disagreement, but rather a caution.
We just spent a phase a couple of months ago completely refactoring our data
validation model to address these very sorts of problems, so it is an issue
that is fresh on my mind.
