Do the exercises one at a time. Submit working solutions only to the Code Critic (Blackboard login required).

The Code Critic

The purpose of the Code Critic is to help you master modern best practices in good software development, such as test-driven development (TDD) and refactoring. Just because code works doesn't mean it's good code. Good code is more than just bug-free. Good code is easy to read and maintain. Software maintenance costs far outweigh development costs. Unfortunately, compilers and unit tests can't tell when code is good code.

Therefore, this course uses a "code - critique - revise - repeat" loop. More specifically:

• Working means that the code compiles, runs, and passes all tests given in the exercise specifications. If you get stuck, use the newsgroup to get help.
  Don't post solutions, buggy or not, to the newsgroup. If you have almost working code and need help, email me. Always put EECS 111 in the subject line.

• I critique your code. Don't be surprised or dismayed if there are more critiques than code.
• You revise and resubmit your code to the Critic.

  Never ignore critiques. If you disagree with or don't understand a critique, email me the specific bit of code in question, the critique, and your question or point of disagreement.

• This repeats until I mark the code as Done. Code not done doesn't count.

To submit code to the Code Critic:

• click to the Blackboard EECS 111 site
• log in to Blackboard with your netid
• click on the Code Critic link

After that, things should be obvious.

The Limit of Two

To avoid making the same mistakes over and over, and, even worse, sending a pile of messy code at the end of the quarter, you are limited to two first submissions in the queue at a time. A submission is a first submission if it's the first code you've sent me for a given exercise. If you have two first submissions in the queue, you won't be able to submit anything else new, but you will be able to resubmit code from previous exercises.