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 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 case you 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
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
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.