Documentation and Coding StyleProjects should begin with your name, UMBC email address, and the project number (e.g., "Project 2") in a comment at the start of the file. This should be followed by a short description of how you solved the assigned problem and of how well your project works, as best you are able to determine. Further documentation requirements may be given in the project handout.Functions and procedures should be accompanied with at least a brief description of what they do and of what their parameters are. Long, complex, or subtle procedures will generally need more careful documentation. Aside from the required documentation you can choose your own coding style, as long as you are consistent with it and it reflects program structure in an effective way. The emacs editor has editing modes for justifying and formatting code, for several languages, which can be helpful in this regard, and examples of reasonable coding styles will be provided for each language used.
Due DatesDue dates are typically days that class meets, and projects are always due by midnight of a due date. Projects can be turned in early for extra credit: there is a 10% bonus for turning in a project two days early or sooner, and a 5% bonus for turning in a project one day early. Projects can also be turned in late, but will be penalized 5% for each day they are late. It is important to plan your time effectively; typically, the biggest trouble students have with projects is simply finishing them on time.
Test DataYou will be given sample test data, but it is not guaranteed to uncover every possible programming error. A major part of a programming project is designing effective tests. Your project will be tested with data that is similar but not necessarily identical to the sample test data. For some projects you will write functions or procedures to be linked with code that I provide. In this case you must use the procedure or function names specified in the project handout, as other names will not work.
Submitting ProgramsYou are to submit a source file (or files, for some projects) which typically contains a number of function, procedure, and data definitions; details will depend on the particular project and language. Do not submit object files or executables. At the top of each file you should include your name and project number. Projects should be submitted as email attachments. A set of files should be submitted as a single attachment in a tar file, with no path prefix.
GradingWorking correctly counts for about half of a project's grade. Partial credit may be given for projects that only work on some subset of the test data. Projects that don't compile don't work correctly. Overly long or inefficient solutions may be penalized. Details as to how points are assigned for correctness, design, documentation, efficiency, and so on, may vary with the project and are given in the project handout.You must do the project that is assigned. Doing some other similar or dissimilar project, no matter how clever, may be worth 0 points. You should understand how your projects works. Exam questions will sometimes cover details of project implementation.
Academic HonestyIt's OK to talk about how to solve problems, but the projects are not group projects. Do not submit other people's work as you own. You should keep your code to yourself; if your project is copied, it may be hard to determine who the real author was.Any help you receive should be documented in a comment at the beginning of your program. For example, if you found a solution to a Lisp exercise in a text or manual, you should cite the source. Reasonable help will not affect your grade; failure to cite your sources is cheating. (The preceding sentence was borrowed from Jim Mayfield's old CMSC 331 syllabus, as was the idea of requiring citations.)
|