- The time that a project is considered "handed in" is determined by the timestamps in the student's handin directory. Projects will be graded by an in-person demo (where the student will demonstrate their programs to the instructor or TA) and a grader's "reading" of the project. (note: we may have projects that do not have demos).
- The maximum score for each project is 100 although some projects may have more points.
- Late policy:
- Late projects will be accepted for a penalty.
- Projects will not be accepted after the scheduled demos (or grading) begins.
- Late projects will be considered either "late" (handed in after due time, but 48 hours) or "very late" (after 48 hours but before 96 hours).
- A student may turn in one project marked as "late".
- After that, late projects will receive a 20 points deduction after grading and a very late project will receive a 40 points deduction after grading i.e. if you get full credit for a project, the actual score you get for a late project is 80 and for a very late project is 60.
- Students are responsible for coming to their demo appointments. If you cannot make your appointment, make an arrangement before the day of the demo.
- Students who simply do not show up for the demos will be penalized depending on the situation. You will lose at least 20 points for the project. If the instructor feels that the situation is serious enough, you will receive no points for the project.
- Generally, the main part of grading projects will be a demo session where you drive your program to show us what it can do.
- Project Evaluation:
- Major part of the grade comes from the demo
- We will look at your code. Therefore, it is important that it is well documented. For example, we might check to see if we can find the place where you implement a certain operation.
- A program that dies gracefully (prints an error message) is much better than one that crashes. Do everything you can to make sure your programs do not crash.
- Your programs should be robust in the face of bogus inputs. Expect us to test this.
Turning in Programs
Programming assignments and projects are to be handed in by placing them in a specified directory. The exact name of this directory will be given in the assignment, but it will generally have the form:
where "yourid" is your CS login id, and "a1" is the name of the assignment (a1 = programming assignment 1, p2 = project 2). If your directory does not exist, or if the permissions are set incorrectly (such that either you cannot write files in it), please contact the TA.
You must turn in all files required to build your program. This includes the source files, the header files, the visual studio project files, and the vis studio solution files. If you use some libraries other than the ones we provide, please make arrangements with us.
You are NOT to turn in executables. Just the source code (and the project files), documentation, and any extra things explicitly asked for in the assignment. You should not turn in "object" files (compiler outputs), debugger data files, library files, etc. We may remove these if you submit it. We may penalize you if you do it more than once.
You must document your code. Everything you hand in should have a "readme.txt" file explaining what each file is. Every file should have a "head" comment explaining what's in it. If you use code written by others as part of your program, you must give proper attribution in both the readme file and the code files themselves.
If you do use code written by someone else (including the instructor or TA or web resource), you should be sure to give that person credit in both your readme file and mark the borrowed code clearly.
Do not work in the handin directory. Copy your files there once the program is working. (there won't be enough disk space for everyone to put all of their working files in the handin directory). You should only copy the following files into the directory:
- the C++ source and header files
- the fluid source files (.fl) if you use fluid (if you don't know what fluid is, don't worry)
- your Visual Studio solution file
- your Visual Studio project file
- any other source files (for example, if you use MFC you would have resource files, or if you used fluid, you would have an ".fl")
- a readme.txt file that explains what your program is, what it does, how to build it, how to use it, what pieces you "borrowed," what each of the files is, ...
In short, we need all the files necesary to build your program (and a readme file). We do not want the executable, the debugging information, the .obj files, ...
Also, you need to configure things so they will compile in the CS environment. If you build your programs at home or somewhere besides a CS machine, you will probably need to change your project settings.