General Information Relating to Programs
Due Dates:
Unless prior arrangements have been made with your instructor (not your
TA), assignments submitted late will not be accepted without a verified
medical excuse from a doctor, or statement of significant personal hardship
or disability verified by either the Undergraduate Computer Science Office
or the Dean of Students. The TAs do not have the authority to accept late
programs.
Back Up Your Work!
Because no work may be submitted late, it is critically important
that you keep a backup copy of your program as you work. A corrupted
diskette or a hard drive crash will not be considered a valid excuse for
turning in a program late. If you normally
save to a diskette, be sure to make a back up on a second diskette.
Backing up to the same diskette is useless. If the diskette is corrupted,
both copies will be gone. If you normally back up to the hard drive, keep
a copy on a diskette as well. If your hard drive crashes, a second copy on
the hard drive will be gone as well as the original.
Back up your program each time you make a significant change or fix a
bug.
Compilation and Execution Requirements:
You must assume that the TA who grades your program will assemble and run
it, so be certain that your program compiles and runs under the
Borland Turbo C compiler used in the lab. This means that if you are
developing
your programs at home (or elsewhere) using a different compiler, or a
different version of the compiler, you must ensure that it compiles and runs using the
compiler provided in the lab. I strongly recommend that you use the Turbo
C compiler for development, since you may find that you must debug twice
if you use another compiler, thus extending considerably the time it takes
you to write a working program.
Allocation of Points:
There are three basic types of points: content points, documentation points,
and style points. The TAs may also choose to give you bonus points for
particularly elegant solutions and may subtract extra penalty points for
particularly egregious mistakes.
With each program, you must include a text-only "Boasts and
Confessions" file. You can use any text editor, such as Notepad or even
the editor that comes with the compiler to create this file. Do not use
a word processor to create a .doc file. In
the event that you cannot complete an assignment, you must
disclose here what the limitations of your program are. For instance, if
your program does not compile, you must state that. Similarly, you must
list any parts of your program that do not work. If you have a partial
solution to your program, it is your responsibility to demonstrate that
the rest of your program does work. This means that you may need to substitute
stubs or drivers for non-working subroutines so that your program assembles
and runs. A stub is a function that does not perform any computation but simply
prints a message stating the name of the function and returns an arbitrary value
of the appropriate type. A driver is a function that calls working functions
only. You must supply a data set which by-passes the non-running part(s)
of your program. If you believe that the non-working part of your program
is the result of a relatively minor error, you may submit the relevant
subroutines (along with any stubs or drivers that you have inserted in
their place to get your program to run) for partial credit, but please
be sure that you have organized and labeled your submissions clearly.
If you add extra functionality to a program beyond what the specifications
require, or if you believe that you have come up with a particularly clever
and/or elegant method of performing all or part of the tasks contained
in your program, be sure to mention it in this section as well. The TAs
are not likely to go searching for things deserving of bonus points, so
do a little bragging so they can find your shining moments easily!
If you feel that your program works fine, but that you have done
nothing extra, then this file should say just that. There is no special
format for this file. You can think of it as an informal "note" to your
TA telling him or her about your program.
EXTREMELY IMPORTANT WARNING!!!
The TA will have a great deal of work to do when programs are submitted.
If you waste his or her time by failing to turn in a boasts and
confessions file, omitting important
information from your "confessions", or by turning in files that are not
well organized and properly named, he or she has the authority to deduct
penalty
points beyond those that the quality of work itself warrants.
Style:
Issues addressed here include the following:
-
Program follows the specifications
-
Global referencing of variables (avoid this like the plague!)
-
Length of program segments (in general, aim for no more than a third of a page
(not including header comments), but under extraordinary circumstances, a
maximum of three quarters of a page)
-
Redundant code (this includes code which has only changes of variable
names)
-
Efficiency
-
Reasonable problem decomposition (top-down design) with attention given
to issues of modifiability, clarity and modularity
-
Abstraction
-
Information Hiding
-
Proper use of encapsulation facilities (e.g., separate files where
appropriate)
Documentation:
Documentation consists of two types: external and internal. External
documentation
is the written material describing the program. Internal documentation
is the documentation that is included as part of your source code file.
You are also expected to use self-documenting code (meaningful identifiers
and clear and simple algorithms wherever possible, etc.).
-
The external documentation for your programs must include a top-down
design.
-
For more complete information about internal documentation, see Coding
Standards.
The internal documentation must include the following:
-
Appropriate Program Comment prologue (name, student ID, date, assignment
number, TA and lab section time)
-
brief problem description
-
Identifier descriptions
-
constants (the name should be self-documenting, but you generally need
to identify how they are to be used)
-
equates (tell how they will be used)
-
variables
-
subroutines and formal parameters (see Coding
Standards for a description of acceptable subroutine prologues)
-
Your implementation section should include the general algorithm you used
-
Be sure your comments section includes:
- Preconditions (assumptions before call)
- Postconditions (assumptions
after return)
-
Program formatting
-
standard tabulation (indenting)
-
consistent use of upper and lower case
-
use of blank lines to enhance readability