Policies on Programming Assignments and Projects
All programming assignments must compile under Visual Studio .NET 2003 as installed in the B240 computing lab. This pretty much means they need to be written in C++ (or C).
All programs must build and run on the computers in B240. If it doesn't run on one of those machines, it doesn't run (in our eyes).
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 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.
Policy on Collaboration
Unless explicitly specified, all assignments and projects are to be done individually.
In practice, helping each other out is valuable. We expect you to talk to each other. However, you should not claim credit for work done by others.
Similarly, in the real world, we often find code resources (nowadays on the web most often) so we don't have to write everything ourselves. In fact, we will provide you with lots of pieces of code to work with. It is important, however, that you do the pieces of the programs yourself that are central to the assignments. For example, in the project on imaging operations, you should implement your own imaging operations. If you are uncertain if a piece of borrowed code is fair game, ask us.
Borrowing code from other students in class (including previous years) is a bad idea unless you get explicit permission first.
If you do use code written by someone else (including the instructor or TA), you should be sure to give that person credit in both your readme file and mark the borrowed code clearly.
The line between helping a friend and cheating is fuzzy. If you are concerned that you might be stepping over to the wrong side of us, contact the instructor.
Some Standards on Evaluation
It is MUCH more important to do the basic/required parts of the assignment correctly than to have bells and whistles. It is very depressing to give someone an F for failing to meet the basic requirements when they have written 5000 lines of code to make a spiffy user interface.
You must be able to use your program. Generally, the main part of grading projects will be a demo session where you drive your program to show us what it can do.
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 things in
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:
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.