Do the exercises one at a time. Submit working solutions only to the Code Critic (Blackboard login required).
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.
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.
To submit code to the Code Critic:
After that, things should be obvious.
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.