re: Is “Defensive Programming” actually healthy? VIEW POST

FULL DISCUSSION
 

It also depends on the nature of the code I develop.

For library code and their public endpoints, that tends to get reused. I go full out defensive. And even at times hostile, in removing functionalities and features to prevent misuse. Classic including not implementing the ability to get password hashes in the user auth library (among other things).

For application code, and one-off code. I relaxed the rule much more on this. If it's safe to assume its current use case will only have "X" params, due to validation being done on another layer, I would sometimes skip checks altogether for it.

 

I like that. It’s very pragmatic. Feels very much like “the middle path.”

code of conduct - report abuse