Laboratory Exercises

CSC 364 -Computer Networks - Weinman

Summary:

Information about expectations for laboratory exercises and methods for preparing to submit them.

Overview

• Collaboration with students outside your group is NOT allowed on laboratory exercises.
• You may use language references to determine relevant language syntax and semantics. Because syntax is standardized, we will consider syntax and semantics to be general knowledge, and you need not cite reference sources.
• You may consult only the textbook and the syntax references for information regarding alorigthms. All non-syntax consultations (including the textbook and references) require formal citation within the related program or exercise.
• You always may consult the instructor and mentor regarding questions on labs or assignments

Submitting laboratory exercises

1. The first five or more lines of any 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 1232

   # CSC 364 Computer Networks

   # Lab 1: Review of Python

   # review.py: Demonstration of Python basics
2. A comment is required for every definition of a function, stating the purpose of the program unit in English. While complete 6-P documentation is not required for every method, it embodies many good practices you may wish to consider. Documenting before you write a procedure can help you plan and clarify the requirements of your implementation.
3. Obtain a nicely formatted PDF listing of your source code using the enscript(1) command:

   $ enscript -p - -Ec -2 -r --color source.c ...  |  ps2pdf - prettysource.pdf

   for C code or

   $ enscript -p - -Epython -2 -r --color source.py ...  |  ps2pdf - prettysource.pdf

   for python code, where prettysource.pdf is the name of the file in which you want the formatted source code stored (enscript generates a PostScript file, which you will pipe to ps2pdf(1) for conversion to PDF.) If your work involves several source files, list the primary program first, then list any supplementary files. Multiple source files can be placed in one call to enscript. While you may also use a wildcard, such as *.c, be sure you only include the files requested for the particular assignment.
4. As appropriate, 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 verify 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 PDF file using enscript(1):

      $ enscript -p - -2 -r transcript  |  ps2pdf - transcript.pdf

      where transcript is the name of the recording file you created above, and the .pdf file is the printable version enscript(1) creates.
5. Concatenate (merge) your program source, transcript, and report etc.

   $ pdfconcat -o submission.pdf prettysource.pdf transcript.pdf
6. If the assignment a PDF and source files, create an archive of your source files and PDF for electronic submission. For example,

   $ tar cf submission.tar submission.pdf source.c ...

   where submission.tar is the name of the archive file you want your files stored in. You may list as many source files on the line as you wish, or even use a wildcard (*.c) Please be sure you do not include any intermediate PDF files or urequested source files.
7. One group member should submit an electronic version of the archive (submission.tar from above, or submission.pdf if no source files are required) online via PioneerWeb by the due date. Be sure you allow enough time to construct your submission before the deadline.

Notes on grading

Requirements

if ( (no_comments)

   || (no_evidence_of_compilation)

   || (no_test_runs) )

return (no_grade);

Style

• Indentation and whitespace that help 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 procedure to fit on much less than 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.
• Code lines that are no wider than 80 characters. This makes them easier to read both on screen and on paper. (Note: If running enscript on your program code produces X lines were wrapped, where X is some number, then your lines are wider than 80 characters and you should re-format your code with additional linebreaks.)

Acknowledgments