Another Programmer Post
When ever I hear the word “should” in any sort of programming context, I have a little sigh inside. I use it pretty frequently, as it’s use is inescapable, but I wish I could cut back.
The problem I have with the occurance of “should” is that it usually indicates that either
- something can go wrong: “You should only have business logic in this clas” vs. “You can’t have business logic in this class”
- something is about to go wrong: “This should work” vs. “We’ve tested this, and it works.”
- something is wrong: “This should be working” vs. “This isn’t working.”
As the examples show, most of my beef with using should is because it’s so damned imprecise. Now, you might call me a bit of a because, much to the consternation of Kim, I often use the weak sounding “sure” when I mean a strong “yes”; as in,
Kim: “Do you want to go out?”
Kim: “No, do you really want to go out?”
Coté:“I said ‘sure.'”
But I think that’s a different issue.
In programming, it seems, whenever you find yourself using the word “should,” something nasty might be lurking just out of view.