6.001 Spring 2005: How should I write up my project? Late homework will not be accepted. In case of illness or absence from MIT make arrangements to complete assignments with your recitation instructor Your TA will examine your project solutions and offer you feedback on them. It's your responsibility to provide clear, convincing answers that are easy to verify. If your work is very messy or disorganized, it will not get full credit even if, after painful examination, it turns out to be mostly correct. You will also need to organize your work for yourself so that you can present it in tutorial and use it for review later. Here are some guidelines Common sense o Put your name on your project o Answer the questions in order o Make it clear when the answer to one exercise stops and the next one starts o Make sure your code is properly"pretty printed", so that the indentations line up. If you are printing out a copy, use a fixed-width font, so that the indentation lines up properly Leave yourself time to write literate, clear answers to all questions. Do not simply submit transcripts of your Scheme sessions Make it clear what you are claiming about each program you submit Attach a clear status description to them, e.g o thoroughly tested using these examples, no known bugs worked on this simple example, no known bugs o looks correct to me but not tested worked on these examples, but failed on these others o syntax error, but I think it 's fixable o there's a bug, but I think it's fixable this is a partial draft Do not include verbatim copies of code that we gave you Include it only have changed a portion or had to incorporate some of it into your own work Learn how to use Edwin buffers to develop your code, and how make extracts from the Scheme transcript buffer. It will save you a lot of time Show examples of your code running on test cases. However, be sure to comment out these cases, so that your entire electronic submission can be treated as a scheme buffer
6.001 Spring 2005: How should I write up my project? Late homework will not be accepted. In case of illness or absence from MIT, make arrangements to complete assignments with your recitation instructor. Your TA will examine your project solutions and offer you feedback on them. It's your responsibility to provide clear, convincing answers that are easy to verify. If your work is very messy or disorganized, it will not get full credit even if, after painful examination, it turns out to be mostly correct. You will also need to organize your work for yourself so that you can present it in tutorial and use it for review later. Here are some guidelines: • Common sense: o Put your name on your project. o Answer the questions in order. o Make it clear when the answer to one exercise stops and the next one starts. o Make sure your code is properly "pretty printed", so that the indentations line up. If you are printing out a copy, use a fixed-width font, so that the indentation lines up properly. • Leave yourself time to write literate, clear answers to all questions. Do not simply submit transcripts of your Scheme sessions. • Make it clear what you are claiming about each program you submit. Attach a clear status description to them, e.g., o "thoroughly tested using these examples, no known bugs" o "worked on this simple example, no known bugs" o "looks correct to me, but not tested" o "worked on these examples, but failed on these others" o "syntax error, but I think it's fixable" o "there's a bug, but I think it's fixable" o "this is a partial draft" • Do not include verbatim copies of code that we gave you. Include it only if have changed a portion or had to incorporate some of it into your own work. • Learn how to use Edwin buffers to develop your code, and how make extracts from the Scheme transcript buffer. It will save you a lot of time. • Show examples of your code running on test cases. However, be sure to comment out these cases, so that your entire electronic submission can be treated as a Scheme buffer
