The Code Critic

Chris Riesbeck
Last updated: July 20, 2009

In my classes, you learn by doing and re-doing:

• You develop a tested working solution to one of the exercises on the exercise page for your course.
• You submit your code for review to the Code Critic link given to you for your course.
• 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 by:

• 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

Rules of the Queue

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 same mistakes.
• 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 wheel.
• 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 correct.

Comments? Let me know!