Programming

OK. Every one knows what KISS means. For those who don’t: “Keep It Simple Stupid". That said, the KISS principle definitely applies to coding, but I think many people that follow it, take it too far. Some do it because they don’t want to spend any more time on a problem than absolutely necessary. Others do it on purpose, following KISS with a fanaticism. I’m sure people will be screaming at me for saying that, but it’s true. (On a side note, when you write code, the rules should not be ignored out of hand, but to follow them fanatically will also cause you grief. If there is no better way to do something, break the rule. You must weigh the options and carefully pick the method that suites you the best.)

When you write code … when you design software or a solution for a bug, you have to stick to your requirements. Don’t go putting stuff in that deviates from what you need. This is really important, because if you add this stuff and it doesn’t get used, then it was a wasted effort. Also, it adds complexity to code, which can add instability.

Now that I have said that, it is important to make sure that your solution does not paint you into a corner for future expansion. I’m not saying that you go nuts trying to put in every feature you can possible conceive. I am saying that if you can write your code about equally in two different ways, one that closes you off for other possibilities, and one that doesn’t, then go with the one that gives you the path to the future so that you don’t have to re-write the code when you do have to add features.

This idea leads to a few other important issues. I had to deal with someone else’s software that was designed to deal with objects spaced every 6 inches. Through out the code there were many assumptions about what the spacing was. For example, hard coded references to one foot divided by two, and to six inches, and other combinations. What ended up happening is that we changed the spacing to three inches. Now, this caused me a lot of grief because I had to find all those references and change them. I could have fixed it in three different ways.

• Change them all to hard coded references to the new spacing.
• Create a variable to assign the spacing to, or make a #define for the spacing.
• Build up an array of spacings or locations, one for each object.

I chose the array because in my situation, it was conceivable that the spacing could become variable for each object. As it turned out, the spacing did change again, to one and a half inches. This meant that due to physical restrains, some of the objects could not be placed on exact boundaries. I knew there were these physical constraints, so I made my choice based on that.

If there was no likely chance of that happening, then I would have gone the #define or single variable route. That way, spacing can be easily changed the next time. it was required.

The moral of this story is that magic numbers are evil and should be avoided at all costs (unless absolutely necessary).