On following rules
It's true that rules are made to be broken, but here are the rules that you never break. Ever.
- Follow every rule you don't understand.
- Only break rules you fully understand and have good reason to break.
There's a real temptation amongst creative types¹ [1And of course programmers are creative types.] that they should be mavericks and rule breakers. That's creative innit? Well, of course it is… up to a point. Creative rule breaking is what separates the good from the really good, the mundane from the sublime. It's also what turns the good into the terrible.
Novices involve themselves in all sorts of rule breaking. Often they don't know that the rule is there, but often they break it because they don't think it applies or they don't understand it. If you're doing this then feel free on your own private projects, but don't to it to one of your customers'. Your creative approach amounts to this:
- Ignore rules you don't understand.
- Any excuse to break a rule is fine.
When put like this it seems obvious why we should follow those rules we don't understand: if we understood it properly then somebody else wouldn't have felt the need to make a rule about it! It's Ok (up to a point) if you're: learning; and the project is a throw-away one; and you're breaking the rule in order to better understand its nature, but it really isn't good if you're trying to do something to a deadline that actually has to work. It is under pressure that the rules have the best utility and when breaking them is most dangerous.
We can only allow ourselves to break rules when we're absolutely sure it'll work because we understand exactly why the rule is as it is. And whilst there are still rules we don't understand we still have a lot of learning to do.
When you examine somebody else's code you'll notice that they break all sorts of rules about how software should be written. You should ask yourself if it is a stroke of genius or a stroke of something a lot less appealing. Did the person truly understand what they were doing or did they just think they did?
When we program there is a well of knowledge for us to draw upon which represents many wasted hours spent solving problems that should never have been. The lessons learned from all these hours have then been condensed into a few good rules. Following the rules won't stop us from doing stupid things, but they will make it more likely that we'll do the right thing.
Some of the rules we all know (and break at our peril)
- Goto considered harmful.
- Use small functions.
- Loose coupling good, tight coupling bad.
- Use meaningful variable and function names.
- Comment what the code leaves out, not what the code already says.
There are lots more.
Man … is successful not because he knows why he ought to observe the rules which he does observe, or is even capable of stating all these rules in words, but because his thinking and acting are governed by rules which have by a process of selection been evolved in the society in which he lives, and which are thus the product of the experience of generations.
Friedrich A. Hayek, Law, Legislation and Liberty, Volume 1: Rules and Order
Pages
