4 ms·
> I think the problem boils down to a violation of separation of concerns. Defensive code inevitably concerns itself with ensuring guarantees about state that i
by mannykannot 5y ago
> I think the problem boils down to a violation of separation of concerns. Defensive code inevitably concerns itself with ensuring guarantees about state that is the concern of other modules.
This is something of a straw man argument. If someone is doing this, they are simply doing it wrong. It is certainly possible to write validations that only check for constraints that must hold within the code they are gatekeeping for.
- marginalia_nu 5y agoThe context of this discussion is adding null checks for parameters that are not explicitly used within the module, thus impairing the ability to test specific parts of the code without instantiating or mocking huge parts of the application. That is, this pattern F(x, y, Z) { if (x == null) bad(); if (y == null) bad(); if (Z == null) bad(); Z.doThing(x, y); } I would argue that Z may have reason to validate x and y, but in this scenario, F only has reason to ensure that Z is not null. What Z does and requires is Z's concern, not F's.
- mannykannot 5y agoThat'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.
- marginalia_nu 5y agoIs 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.
- mannykannot 5y ago> 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.
- marginalia_nu 5y agoIt'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.) In which way am I misrepresenting it?
- mannykannot 5y agoThat's just the same straw man that you are also arguing against! As for your anecdotal evidence, it does not count twice through repetition.
- marginalia_nu 5y agoWhy wouldn't anecdotal evidence count? 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.
- mannykannot 5y agoIt 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. Yes - it started with a straw man in the article.