Overview

This course features weekly laboratory exercises, as listed on the course schedule.

• Unless otherwise stated:
• collaboration IS allowed on laboratory exercises.
• you may use language references to determine relevant C syntax and semantics. Since C syntax is standardized, we will consider C syntax and semantics to be "general knowledge", and you need not cite reference sources.
• you may consult only the textbook and the C syntax references for information regarding alorigthms. All non-syntax consultations (including the textbook and C references) require formal citation within the related program or exercise.
• You always may consult the instructor regarding questions on labs or assignments (at least if the instructor is in his office with the door open).
• Programs (source code, compilation, and output) are to be submitted in the format below.

Submitting Programs

In turning in any programs for the course, please follow these directions:

1. The first seven or more lines of any C program should be comments containing your name, your mailbox number, your lab section, an identification of assignment being solved, and a description of the contents of the file. For example:

    
         /*************************************************************************
          * Jerod Weinman  
          * Box Science II
          * Laboratory Section 213L.01
          * Lab 1: Review of C; Sorting and Order Statistics
          * arraylib.c: Definitions of useful functions to manipulate arrays
          ************************************************************************/
       

2. A comment is required for every definition of a C function, stating in English what that program unit is supposed to do.
3. Obtain a nicely formatted listing of your source code.

   Create a pretty and printable file using the enscript(1) command:

   enscript -Ec -2 -r --color -p prettysource.ps source.c ...
   where prettsource.ps is the name of the file in which you want the formatted source code stored (enscript(1) generates a PostScript file, hence the ".ps" extension.) If your work involves several C files, list the primary program first, then list any supplementary files. List .h files before their corresponding .c files. Multiple source files can be placed in one call to enscript(1).
4. If you have multiple C source files, create an archive of them for electronic submission. For example,
   tar cf sources.tar source.h source.c ...
   where sources.tar is the name of the archive file you want your program source files stored in. You may list as many source files on line as you wish. You may also add an entire directory to an archive by including the directory name without a trailing "/" in the list of files. If you do this to include the entire lab directory, please be sure you do not include any binaries, object files, etc.
5. Create a transcript of your program's compilation and output runs using the script(1) command:
   1. In a terminal window, start recording output to a file called transcript with the command:
      script transcript
   2. Compile your program with gcc or make as appropriate.
   3. Run your program with appropriate test cases to check its correctness.
   4. When your runs are complete, stop the script session by typing Ctrl-D.
   5. Convert the recorded text file to a nice, printable PostScript file using enscript(1):
      enscript -2 -r -p transcript.ps transcript
      where transcript is the name of the recording file you created above, and the ".ps" file is the printable version enscript(1) creates.
6. Concatenate and print your program listing and transcript, i.e.,
   cat prettysource.ps transcript.ps | lpr -Pprinter
   where printer is the name of the printer you want to send the output to.

7. Include a separate statement that argues why your program is correct, based upon the evidence from your test runs. You should also include the answers to any questions or experimental results/write-ups required for the lab.

   You may use a word processor to format such statements, or you may use a simple text file. You may easily incorporate a text file into your submission by including it in the transcript. Between 4.c and 4.d,

   cat statement.txt

8. One group member should submit:
   1. your printed work at the beginning of class on the day it is due, AND
   2. an electronic version of the source file archive (source.tar from 4 above) online via PioneerWeb by the beginning of class.
   The late policy applies to both portions of the submission jointly (e.g., if one portion is late both are considered late.)

Notes on Grading

Requirements

Since every programming task should yield readable and carefully tested code, the grading of all programs for this course will begin with the following algorithm (expressed in C format):

    if (  (no_comments)
       || (no_evidence_of_compilation)
       || (no_test_runs)
       || (no_commentary_on_correctness))
    return (no_grade);
  

When a program is submitted according to the format specified above, it should be understood that the transcript reflects a complete session of program listing, compilation, and running. With this understanding, editing of any script file is strictly forbidden and will result in automatic failure on the assignment. Such editing also may raise questions of academic dishonesty; and, by College policy, any evidence of academic dishonesty must be turned over to the Academic Standing Committee for action.

Style

Because code maintainability is an important part of development, your labs will be graded in part on style, as well as correctness. After all, if I cannot understand your code (or it takes me too long to), I cannot give it a grade regarding its correctness.

Some style matters I care about that you may want to consider:

• Indentation/whitespace that helps delineate code blocks. (Most editors will help you with this.)
• Helpful comments on blocks of code or particularly complicated expressions
• Functions that are reasonably small. (A very good guideline I try to follow is getting an entire function to fit on one screen; this makes interpreting a function's action more readable by forcing you to break it down into named steps that can be seen at once. It also promotes easier debugging and unit testing.)