We’ve all done it: snagged a cookie when mom wasn’t looking, had a little too much wine for dinner, let the car sit in a parking spot after the meter expired. We’ve even gone around Deadman’s Curve a bit too fast. And yes, we’ve all violated any number of the cardinal rules of programming, the ones that everyone agrees are bad. And we secretly liked it.
We’ve thumbed our nose at the rules of good programming, typed out code that is totally bad—and we’ve lived. There were no lightning bolts from the programming gods. Our desktops didn’t explode. In fact, our code compiled and shipped, and the customers seemed happy enough.
That’s because bad programming isn’t in the same league as, say, licking an electric fence or pulling the tail of a tiger. Most of the time, it works out. The rules are more often guidelines or stylistic suggestions, not hard-and-fast directives that must be obeyed or code death will follow. Sure, your code might be ridiculed, possibly even publicly. But the fact that you’re bucking conventions adds a little bit of the thrill to subverting, even inadvertently, what amounts to (more often than not) the social mores of pleasant code.
