CS325 Process

What you do, what I do

You code, you test, I critique. Testing looks for bugs in your code. Critiquing looks for things testing can't find, such as

• maintainability: modularity, naming, structure, etc.
• appropriate use of a programming language and its libraries

This course is about going beyond being someone who can get a program to work, to being someone who can write clean maintainable code that developers enjoy working on. Although this course uses Lisp and JavaScript, most of the critiques about maintainability apply to all programming languages.

The Cycle

Here's how the process works:

• You select an exercise and send me a working solution.
• I critique your solution and return it to you.
• You revise and resubmit your solution.
• We repeat this cycle until I have no more critiques.
• You repeat this process for many exercises until the course ends.

Expect to re-do most things, especially early on. Normally, you should have two or three different exercises going through the revision cycle in parallel.

Grading

I do not grade solutions. Either a solution is fine, or it needs work.

You do get a course grade. It is based on three factors:

• Progress: How far did you get? How many different kinds of problems did you do? How difficult were these problems? How many different topics did you explore? How many skills did you demonstrate?
• Quality: How good is your code by the end of the course? What level of critiques are you getting?
• Effort: How often and how steadily did you submit, including revisions? How hard did you push yourself from your personal starting point?

See the Frequently Asked Queue Questions for what your pace of submissions should be.

Details

Selecting Exercises

The Exercise Page lists the approved exercises for this course. They are bundled by topic and separated by difficulty. It is your choice which topics to do first. A good strategy in general is to do a few easy exercises in a topic first, then jump to a challenge in that topic when you feel ready.

If you are very new to programming or Lisp-like languages, do earlier bundles first. If you are more experienced, jump directly later bundles. If you encounter problems, or receive an inordinate number of critiques, go back to earlier bundles.

Submitting Solutions

• Use the web-based Code Critic to submit working solutions.

  Working means that the code has been cleared by both the Unit Tester and the Lisp Critic tools.

• You will receive an email when I have critiqued your code.
• Respond to all of the critiques by revising and resubmitting your code.
  • Only resubmit code that you changed. Don't resubmit code marked OK.
  • Don't ignore critiques. If you don't understand or agree with a critique, send me email containing (in plain text) the code, the critique, and your response. Put CS325: in the Subject line and the name of the exercise.
• Repeat this cycle until the exercise is marked done.
• There is a limit on how many new exercises you can submit at once.

See the Code Critic FAQ for common questions about this process.

The Code Critic

Submit solutions through the Code Critic link on Canvas. The Code Critic is also where you can see a complete history of your submissions.

The Code Critic is for solutions only. Do not use the Code Critic for discussion or messages.

If you have trouble accessing the Code Critic, post to Piazza.

If you want to ask about a critique, see above.

Don't send code for review to email. I will just tell you to submit it to the Code Critic. You'll end up later in the queue than you would have had you sent it directly there.

The Rules of the Queue

Here are the rules for normal exercise submissionsm:

• No untested or partially working code -- I really really hate getting code that doesn't pass all the tests.
• No code output -- unless requested by the exercise
• No testing code -- unless requested by the exercise
• No book code -- only send code you wrote
• No comments -- comments are a bad idea anyway, really, trust me; it's OK however to use a comment to ask me a question

Plagiarism

Plagiarism is unacceptable.

Code you submit to the Code Critic must be your own. That means no studying, copying, adapting, and/or submitting answers to exercises from a Github repository or a friend is allowed, and no use of any code generation tool, such as CoPilot, ChatGPT, and the like.

Copying and studying working code makes sense when your goal is building an application. But your goal in this course is learning how to be the person who writes the code you copy.

If I believe copying has occurred, I will submit the evidence to your dean. Since cheating on some exercises calls into question all the code you've done, and your grade is based entirely on your code, the effect on your course grade may be substantial.

How To Do Well

Challenge yourself. There's no point to sending me code that was trivial for you to do. It proves nothing about what you know. If everything in the textbook was easy, let me know. I'm sure I can challenge you.

Submit at a steady pace. Send at least 2 to 3 pieces of new code a week. If you send less, you'll fall behind.

Re-test after every change. No matter how trivial you think the change is, run the tests just before submitting. You'd be surprised how often you break something with a small change.

Don't get stuck. Work on several problems in parallel. If you can't get something to pass all the tests, or if there's an error message you can't decipher, and you've devoted several hours to the problem, get help.

What I'm looking for

The skills to be demonstrated can be measured along these dimensions:

• Maintainability of code produced:
  • Readability: Good names, the Cardinal Rule of Functions, good use of whitespace, "short attention span programming"
  • Modularity: coherent modules, well-defined module interfaces, no unnecessary shared global variables
  • Appropriateness: appropriate use of built-in Common Lisp functions, data structure, and control flow constructs
  • Documentation: commenting (what not how)
• Quality of code produced:
  • Coverage: range of inputs handled, errors handled
  • Adequacy: appropriate depth of representation, range of inferences supported, "thickness of interface"
• Quantity of code produced:
  • This is the least interesting dimension, but if you're not writing very much, or take forever to do something simple, then there's a problem.