Top Ten Things To Take With You From This Course

Never Copy Code. Use Abstraction Instead.
Modern programming languages help you express abstractions. Primitive ones make it more difficult. But thinking of them is the hard part. Don't give in to the temptation of letting the editor's copy button determine your program's organization.

Don't Guess. Reason!
Formulate a sound reason for every element of your program. It's tempting to guess at a solution, then try it to see if it works. The trouble is, you never really know it works. Unless you have reasoned precisely, all you will know is that your solution works in the particular test cases you have tried.

Study Your Code. Don't Fiddle With It.
If you must trace partial results, write down a hypothesis about the problem first. If you don't do this, you're just fiddling around, and you will waste about nine minutes out of every ten.

Know What Your Loops Do.
If you can't express the invariant property of a loop, you don't know what it does.

Organize Programs as Collections of Small Modules.
Be careful about which entities you make public. And, try to organize your modules so that they don't contain too many entities. Two dozen is about the limit. If a module gets larger than that, rethink, and try to organize it into a primary module with some sub-modules.

Be Clear About Which Entities You're Importing.
If you lose track of which entities one module needs from another, reorganizing your program, which will be necessary eventually, will be a nightmare.

Build Prototypes in Haskell.
Modern languages keep track of lots of details, freeing you to think about the real intellectual challenges. When you get it right, then reuse your program organization and fundamental concepts in whatever target language you're stuck with for the project. Don't succumb to the conceit that worrying about the details doesn't really cost you. The smarter you are, the more important it is for you to concentrate on the intellectual challenges rather than the grungy details. Haskell and languages like it help you do this.

Get It Right First.
Then measure computing resource usage and optimize where necessary. Experience shows that programmers almost never correctly predict which parts of their programs will consume the most time or space.

Choose Names Well.
Invest what seems like inordinate amounts of time in choosing good names for the entities you define. And don't be afraid to change them if you think of better ones. The names of things are often the best form of internal documentation in software.

Think Before You Type.
Too many software developers spend 90% of their time typing and 10% thinking. The most effective software developers spend 90% of their time thinking and 10% typing. Don't rush to the keyboard. Think. Create. Plan. Revise. Rethink. Then type a little. Then do some more thinking. Well, OK - you can use the keyboard as a pencil if you find that effective. But don't use it as an analytical tool. You are smarter than your keyboard, your compiler, and your debugger.

CS 1323 Section 30 - Fundamentals of Computer Programming - Spring 1997
Instructor: Rex Page (Email: page@ou.edu)
Up to: Welcome Page ~~~ Up to: University of Oklahoma ~~~ Go to: Next Semester ~~~ Go to: Previous Semester
Last Modified: Friday, 02-Dec-2005 11:43:35 CST