Paul Vick posted these Seven Rules for Beginning Programmers earlier this week and I have been thinking about them a lot. They make sense to me. As a professional developer you have to understand that these are the rules for beginners. The last item concludes with “You may go beyond these rules after you have thoroughly understood and mastered them.” It is important to remember that there are few absolutes but at the same time beginners need to exercise some caution while they are mastering the basics. Though honestly, even professionals should “Never use language features whose meaning [they] are not sure of.” Of course there should be fewer of those for experienced professionals than for beginners. Here is Paul’s list.
- Do not write long procedures. A procedure should not have more than ten or twelve lines.
- Each procedure should have a clear purpose. It should not overlap in purpose with the procedures that went before or come after. A good program is a series of clear, non-overlapping procedures.
- Do not use fancy language features. If you’re using something more than variable declarations, procedure calls, control flow statements and arithmetic operators, there is something wrong. The use of simple language features compels you to think about what you are writing. Even difficult algorithms can be broken down into simple language features.
- Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.
- The beginner should avoid using copy and paste, except when copying code from one program they have written to a new one they are writing. Use as few files as possible.
- Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]
- Every day, for six months at least, practice programming in this way. Short statements; short, clear, concrete procedures. It may be awkward, but it’s training you in the use of a programming language. It may even be getting rid of the bad programming language habits you picked up at the university. You may go beyond these rules after you have thoroughly understood and mastered them.
I expect some to take exception with something in rule 7 - “getting rid of the bad programming language habits you picked up at the university” After all isn’t the purpose of a university education to learn “the right way” to do things? Sort of. But the truth is that the types of projects that most complete as part of their education don’t always lead to best practices. The problem is size of the projects and also, in many cases, the artificiality of the projects. They have to be both small and somewhat artificial to fit in the concepts that are being taught. And in some schools software engineering is a dirty word (term) in computer science programs. That’s not all bad as long as people who become software developers understand that they have things to learn about design and about creating large scale projects.
Copy and paste is another interesting case and I am glad to see it on the list. There a huge temptation to copy and paste. Sometimes the idea is to use the new code as is in which case one should really think about encapsulating the code in a method, function or subroutine. Or the idea is to copy/paste and then make a little modification. The problem with that is that one invariably misses something in the process. And of course you also have the possibility of copying something that is wrong, buggy or just plain not as close a fit as you thought. Copy/paste means trouble later if far too many cases for beginners to use it as often as they seem to like to do.
So what do you think of these rules? I see that Garth is planning on posting them in his lab. Would you consider doing the same thing?