That's what I am saying - your argument boils down to "bad validation is harmful" - true, but hardly controversial; bad code in general tends to be harmful.
Is it controversial to state that defensive programming boils down to "more validation is better"?
This is a style of programming I've seen in the field, and it's seemed to emerge within code bases with major data quality problems, but done little to actually fix the problem. You're less likely to get disastrous train wrecks, but the number of errors largely remains the same unless the cause is addressed.
> Is it controversial to state that defensive programming boils down to "more validation is better"?
It is a straw man to take this as being intended to justify incorrect and useless validation.
If this is something to be decided by personal anecdote, I will just add mine: I haven't seen this, while I have seen many cases where validation has picked up subtle and edge-case errors.
It's probably fallen out of favor, but I saw it a lot around the same time the OP was written, late-2000s, early 2010s.
Look, this is the paragraph we are discussing:
> Be Defensive - They're out to Get Your Code! - Defensively assert about the state of parameters passed in methods, constructors, and mid-method. If someone can pass in a null, you've left your guard down. You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls! Be aggressive in preventing this: rule your code with an iron fist! (And remember: it's not paranoia if they really are out to get you.)
This may not be the flavor of defensive programming you favor, but it is something that exists, and also something that is explicitly mentioned in the start of the discussion.
It counts for something, but yours does not count more than anyone else's - and it is certainly not sufficient to make a general case against validation. Pointing out that bad or incorrect validation is bad is news to no-one, and is merely a specific case of bad code being harmful.
>...something that is explicitly mentioned in the start of the discussion.
