DEV Community

Discussion on: Is “Defensive Programming” actually healthy?

Collapse
 
seveneye profile image
seveneye • Edited

i think it depends on how complex it will be when you try to be "defensive". There are times that the code gets too complex to understand because we're trying to handle a lot of cases, when it is just a simple feature.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

Simple features have a habit of becoming complex features as time progresses and the application grows. That’s why defensive programming provides a foundation so you can grow the program without worrying.

Collapse
 
seveneye profile image
seveneye

It takes experience to determine which simple features have the potential to be a complex one. If the code gets too complex and I'm spendin too much time, I will always revert to KISS and YAGNI and not be paranoid about future use cases because it will show up anyway and we need to do some CR/Bug/Enhancement about it. I focus more on good design so that code can be easily refactored.

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

If you’re waiting til someone makes a bug report, then you’re waiting too long. That’s by definition reactive. The approach in this article is proactive.

The best bug is the one that never makes it to production.

Thread Thread
 
seveneye profile image
seveneye • Edited

yeah, tho i still think it should be a balance, you can never be too proactive because it might be costing you too much time, when you can just design it better. If you are already good at it then that's awesome.

In your example, in order to create add new traffic signal, you don't file a bug. You need enhancement for that and you can refactor the code the way you did. But in other cases, simple code that only handles 1 case but made too complex will be a maintenance nightmare for you and your team.