3 ms·
Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing
by abhishekpathak 9y ago
Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.
- bostik 9y agoI'm somewhat of two minds here, to be honest. First, depending on the situation I can find myself practicing "Paranoid Programming". It's an approach I picked up in my C days when I had to deal with network protocol code. Essentially: switch-case with every conceivable error condition handled and then the happy path as the final, unlikely edge case (Also: "default" case always triggered an error.) On the other hand it's a really depressing way to write code. When 80% or more of your dispatcher logic is dedicated to error handling, following the actual logic can be really cumbersome. On the positive side, once you are in the proper code, you have far less edge cases to worry about.