On Handing in Programming Assignments
Format
Each assignment should be handed in with the following components, in this
order:
-
cover sheet
-
source code
-
input and output
The cover sheet should give your name, the course name/number, the assignment
number, your UNIX login name (NOT passsword), and your email address. Each page should have your name on
it as well. For your source code, each page should also be labeled
by the filename and page number within that file.
Style, Formatting, and Comments
Here are my expectations regarding what your source code should look like.
Note that these issues will affect your grade.
Your source code must be readable:
-
"Jump" statements such as goto, break, continue
should not be used (with the exception of using break in
switch
statements). Similarly, you should generally not return from a
function in the middle of a loop. These techniques usually
indicate that you have not thought through the program logic clearly.
Rewrite your code/loop/whatever to avoid these -- this may indeed result
in slightly longer source code, but it should be easier for someone else
to understand.
- NEVER call main(), and if you are using recursion, be
sure you understand it.
-
Don't use global variables. Pass values to functions using parameter
lists -- that's what they're for.
-
Each function you use (including main) shouldn't be much longer
than a page.
You should make reasonable and consistent use of indentation and blank
lines: the details are up to you. One of the best ways to do
this is to find a C++ book that has a style you like, and adopt it as your
own.
Identifiers should be self-documenting; that is, the names you choose
should make their roles reasonably clear (with the possible exception of
simple counters, for which names like i and j are acceptable).
Brief comments for each identifier are useful.
Comments should describe the structure and approach of your program:
-
A comment at the top of your program should explain its purpose and describe
the input and output.
-
Each function should have a comment describing the parameters, return values,
and purpose of the function.
-
Major loops, complex if statements, and other significant sections
of code should have comments describing their purpose.
-
Smaller (sub)sections of code should have a brief comment if they do something
relatively complex or non-obvious.
-
Individual lines of code should not, in general, be commented, unless
they do something really sneaky -- but if this is the case you should
consider rewriting your code to make it clearer.
Input and Output
In general, I expect you to test your program using a variety of inputs.
Depending on how the assignment is structured, this might entail running
your program several times, or it might mean just running your program
once. Unless the assignment specifies otherwise, you should deal
with input and output as follows:
-
Input for one run of the program should be stored in a data file.
If you will run your program several times, you will need several input
files.
-
As part of its output, your program should "echo" its input, clearly labeled.
For example, a program to sum three integers should produce output that looks something
like this:
Integers to sum: 7 17 61
Sum: 85
-
Print out the output from each execution and hand it in. Each output
printout should immediately follow the printout of the input that generated
it.
-
Unless otherwise specified by the assignment, your program should be written
to take input from the keyboard and print to the screen (i.e. don't use
any file-related code in your program). We will discuss in class
how to use the UNIX redirection operators (< and
>) to simplify working with input and output.
If Your Program Doesn't Work
This is important!
In the (unlikely) event you are unable to generate meaningful output (most
likely due to compiler error, or possibly severe problems running the program)
you should instead do the following:
-
If the problem is due to unresolved compiler errors, provide a printout
of the errors
-
If the problem is due to some kind of runtime problems, provide a printout
of the program's output.
You must also write (by hand, if you like -- legibly) an explanation of
what you believe the problem to be and what you would do if you had more
time to fix it.
Without either meaningful output or an explanation of the problem,
your work will get a 0.