Thursday 28 January 2010

Do as I say, please

Recently I have been thinking about the old adage 'Do as I say not as I do'. This has been on my mind a lot since my recent entry on the usefulness of variables and their use in combating the problems caused by magic numbers

This is sound advice (trust me) but the thing is, I, as well as many other programmers, are guilty of breaking this rule, a lot (even though they'll tell you they don't). We will probably regret breaking it and curse ourselves for taking the short cut, but it does happen.

In an attempt to maintain the use of such a rule, one must try to apply it at all times, unless a set of requirements are met in which it is appropriate not to do so. So given a certain context, the rule can be broken, but one should ensure the reasons for breaking it are sound and justified. So an example of where using magic numbers may be acceptable is rapid prototyping or throw away prototyping where the object is to get something working as quickly as possible, and the code does not need to be maintained or reused. This would be a time where the rule does not need to be followed to the letter, but you can bet at most other times you should take heed of it.

Other examples of certain approaches which are regarded as dangerous or bad practice are things such as multiple inheritance or use of the goto statement. You are told to avoid such things (which I personally would!) but again you'll find times where it may be appropriate to apply them. Emphasis is placed on them to ensure that if you ever find your self having to implement such a design, you are acutely aware of the potential traps you can fall into, and why they are dangerous to use. (It's also worth adding a host of comments to explain your rationale to other friendly programmers!)

I guess, putting it as plainly as possible, you should take these things with a pinch of salt. These ideas are usually a good thing to follow, especially when you are starting out, but there will always be exceptions, the trick is knowing what they are and when to use them.

No comments: