Many people these days fail to understand the purpose of a readme file (you're probably thinking, those daft TAs, just giving us extra busy work as if we don't already have enough....) Here, then, is a brief outline of a good readme file for any assignment:
===============
Here is a bad readme file. The stuff in []'s is what the TA might imagine the student is thinking:
"For this program, I created 3 classes [but I'm not going to tell you what they are, or I don't know what they are. Also I don't know what files I put them in. It's guess-the-class time.]. The user will be asked for 3 things [but I don't know what they are, or I'm not going to tell you what they are. Also, I'm not sure how the user should input those things, or in what order, or how I'm going to use them.]. Then I'll print the output [but I don't know what it looks like, and I'm certainly not going to tell you or give you any examples in case you can't figure out on your own what the input is and so can't produce your own output....].
"I like this project [but I can't tell you what files I put my work in, or how to compile them.]."
By not turning in a proper readme file, you indicate that you want to annoy the person marking your project as much as possible, or at the very least that you didn't properly design and test your solution.
By turning in a proper readme file, you not only demonstrate the competence of your solution, you also clarify what exactly you have done (especially helpful if you did something "extra".) If any files get lost, we will know from your readme file. Writing a good readme file also gives you the opportunity to check and make sure you have done everything; to "organize" yourself. Finally, it means that 7 months from now you will be able to go back and figure out what exactly you did and how you might be able to reuse some of your code.
Please turn in a good readme file.