Condividi tramite

Seven Rules for Beginning Programmers

  • Articolo

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. Smile Here is Paul’s list.

  1. Do not write long procedures. A procedure should not have more than ten or twelve lines.
  2. 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.
  3. 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.
  4. Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.
  5. 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.
  6. Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged. ]
  7. 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?

Comments

  • Anonymous
    May 18, 2011
    The comment has been removed

  • Anonymous
    May 19, 2011
    Hmmm. I'm not convinced that mapping good advice from one field to another is always a win. Some aspects of programming are a bit like writing, but by no means all. I can why short methods might be a good idea, but not to the point that programs are broken into chunks just to obey this rule. And rule 6 is disasterous, very few beginning programmers would understand it at all. And by the time they did understand it, it would not be required. Writing a list of rules like this might make people worried about more than they should. In my experience people learning to program often fret about whether they are doing the right thing or not. Adding more rules (and then saying that they can forget some of them when they become "proper" programmers) is not really doing them a favour. My preference when teaching is to get them to write something that mostly works and then go through it with them making all the salient points above in a context that they understand.  The other thing to remember is the sad fact that the customer won't care a hoot whether or not these rules are broken in the solution as supplied. If it works and does what he/she wants then that's a win.

  • Anonymous
    May 20, 2011
    @Rob Miles - Your last two lines say it all.  Code should be clean and supportable by others, but in the end you must satisfy the customer with working software.