I’ve always thought defensive programming was evil (and I still do), because typically defensive programming in my experience has always involved some sort of unreasonable sacrifices based on unpredictable outcomes. For example, I’ve seen a lot of people try to code defensively against their own co-workers. They’ll do things “just in case” the code changes in some way later on. They end up sacrificing performance in some way, or they’ll resort to some silver bullet for all circumstances.
This specific coding practice, does it count as defensive programming? If not, what would this practice be called?
Wikipedia defines defensive programming as a guard for unpredictable usage of the software, but does not indicate defensive programming strategies for code integrity against other programmers, so I’m not sure if it applies, nor what this is called.
Basically I want to be able to argue with the people that do this and tell them what they are doing is wrong, in a professional way. I want to be able to objectively argue against this because it does more harm than good.
“Overengineering” is wrong.
“Defensive Programming” is Good.
It takes wisdom, experience … and maybe a standing policy of frequent code reviews … to tell the difference.