Week 10

Turtle Graphics page with documentation.

On Wednesday, I gave some “secrets” of programming:

Secrets of Programming

Specifications

Every program should have two parts:

1. A specification, usually informal text in comments, that explains how and why your program works.
2. The implementation, i.e. the code.

Rather than making the code solve your problem directly, you should focus on making the code do exactly what your specification says it does. As you work, you will find both errors in the specification and in the implementation. The problem with writing code directly with English descriptions is that code is too detailed and hard to reason about. Having two perspectives on the problem and its solution is invaluable.

Incremental Development

Start with a simple program that works and modify it incrementally, adding new features one-at-a-time until your program is finished. Test at every step. If you encounter a problem, it will almost always be related to the last change you made, which is both small and fresh in your mind, and therefore quick and easy to fix.

Rubine’s Rule

If you find a bug, fix it. (Due to Dean Rubine, programmer extraordinaire.) Programmers often think they can pursue one problem while ignoring other “unrelated” problems. Those “unrelated” problems are often critical and your misunderstanding of them will cause all sorts of confusion. To avoid getting nailed by your own misundertanding: if you find a bug, fix it.

Write Quality Code

Do not tolerate sloppy code, especially if it is yours. In the words of a former student, you should love yourself and therefore love your code, which is yet another manifestation of who you are. In a way, good code, good art, and good writing are all part of being the person you want to be. Making things of quality may seem more difficult, but if you develop a strong habit of being careful, demanding, critical and exacting, you will find that it actually makes coding easier.