In this class, you learn by doing and re-doing:
- You develop a tested working
solution to one of the exercises.
- You submit your code for review at
the 211 Code Critic
- I critique the code.
- Unless you turn this off, you get an email that your code has been critiqued.
- You review the critiques. If changes are needed, you create a new tested working solution,
and resubmit for further review.
- If the solution is marked Done, you move on to the next exercise.
- Repeat until you're a programming wizard.
I try to respond to code submissions within a day. However, so much code
comes in over the weekend, that it usually takes a couple of days to clear the
Monday morning queue. The Code Critic page shows you how long the queue is
and where your submissions are in the queue. Be patient, but if several days go by
and it seems like your submission has been overlooked, email me.
No grades are given on individual exercises. Your course grade is determined
- Productivity: The number of different exercises and chapters you manage to cover
- Quality: The quality of your initial submissions as the course progresses, i.e.,
what critiques you don't get any more
- Effort: The number and content
of the submissions and re-submissions you make
Getting critiques is not a bad thing. That's how you learn.
Expect many critiques, especially early on. Expect
to re-do most solutions at least once, and sometimes three or four times.
This is normal and part of the process.
The two things to avoid are:
- getting the same critiques over and over -- that
means you're not learning
- not submitting code for review several times a week -- that means
you're fallling behind
For the critiquing process to work smoothing and fairly,
there are a few important rules. Submissions that violate one or more
rules will be returned unreviewed for correction.
- Submit only tested working code.
- Submit only what's asked for. I rarely want the entire application.
- Don't combine exercises into one submission. The exercise pages make it
clear what goes in each submission.
- Include the file name in each file.
- Fix and resubmit any code marked as not done or almost done. Only code
marked done will count in your final grade.
- Resubmit only functions you've changed. Don't send unchanged
code that was approved already.
- The Limit of Two: Do not put more than two first submissions
in the queue at once. A first submission is the first version of code you
send in for an exercise. This limit reduces repeated critiques for the
- Do not ignore critiques. If you disagree, email me the critique, the lines of code it
applied to, and why you disagree.
- Use the newsgroup to get help. Post lines that don't compile and
copies (not paraphrases) of error messages. Include what
platform you're using. Do not post full programs, even broken ones.
Pace yourself. Don't fall behind. Submit and re-submit steadily.
Because of the Limit of Two, you can't send a flood of submissions
late in the course.
Include the file name in each file.
Because you will often be submitting several short files in a batch to
the Code Critic, it's important that every file start with a brief identifying line.
- Start C++ files with // filename.
- Start Makefiles with # project Project.
Tips for writing good code the first time
- Avoid repeated code. Define subfunctions when they make the code clearer. You will be
critiqued for not defining subfunctions when they're appropriate.
- Define variables when they make code clearer, or more efficient.
- Unless told otherwise, use the functions and containers in
the standard C++ libraries,
when appropriate. Don't reinvent the
- Use names to document your code. Read
the naming section
of "How to Write Unmaintainable Code,"
and do the opposite.
- Use whitespace wisely. Follow the indentation and spacing
patterns of the examples in the textbook and the C++ style guide.
- Check your answers. Just because the computer printed it, doesn't mean it's
Send mail to Chris