CS140 -- Labs

  1. Lab Assignments
  2. General Stuff
  3. Lab Sections
  4. Lab Attendance
  5. Pair Programming
  6. Late Labs
  7. Lab Submission Info
  8. Plagiarism Policy
  9. Making Your Code Readable

Lab Assignments

Lab Due Date Grading Guide Reading Assignment
Lab 1
  • Fri Lab: 11:15AM, Friday, Aug. 27
  • Mon Labs: 2:30PM, Monday, Aug. 30
guide none
Lab 2
  • Fri Lab: 11:15AM, Friday, Sep. 10
  • Mon Labs: 2:30PM, Tues, Sep. 13
Lab 3
  • Fri Lab: 11:15AM, Friday, Sep. 17
  • Mon Labs: 2:30PM, Monday, Sep. 20
guide Kochan: Ch. 18, pp 395-409 (gdb)
Lab 4
  • Fri Lab: 11:15AM, Friday, Sep. 24
  • Mon Labs: 2:30PM, Monday, Sep. 27
guide none
Lab 5
  • Fri Lab: 11:15AM, Friday, Oct. 1
  • Mon Labs: 2:30PM, Monday, Oct. 4
guide none
Lab 6
  • Fri Lab: 11:15AM, Tuesday, Oct. 12
  • Mon Labs: 2:30PM, Thursday, Oct. 14
guide None
Lab 7
  • Fri Lab: 11:15AM, Friday, Oct. 22
  • Mon Labs: 2:30PM, Monday, Oct. 25
guide Look over the following three files. You will be modifying them at the start of lab so that they do information hiding with void *'s:
Lab 8
  • Fri Lab: 11:15AM, Friday, Oct. 29
  • Mon Labs: 2:30PM, Monday, Nov. 1
Lab 9
  • Fri Lab: 11:15AM, Friday, Nov. 5
  • Mon Labs: 2:30PM, Monday, Nov. 8
guide Make sure you complete the lab homework (found in the lab writeup) before lab
Lab 10
  • Fri Lab:
    • Parts 1 and 2: 11:15AM, Tuesday, Nov. 16
    • Parts 3 and 4: 11:15AM, Friday, Nov. 19
  • Mon Lab:
    • Parts 1 and 2: 2:30PM, Friday, Nov. 19
    • Parts 3 and 4: 2:30PM, Monday, Nov. 22
guide Make sure you read the lab assignment before lab so that you can immediately start doing the design questions during lab
Lab 11
  • Fri Lab: 11:15AM, Tuesday, Nov. 30
  • Mon Labs: 2:30PM, Friday, Dec. 3
guide Make sure you complete the lab homework (found in the lab writeup) before lab

General Stuff

Lab Sections

Date Room
Monday 2:30-5:30Claxton 103
Monday 2:30-5:30Claxton 105
Friday 11:15-2:15Claxton 103

Lab Attendance

Lab attendance is mandatory for the entire time of the lab, unless you have already submitted the lab. If a lab is a multi-week lab you must attend each lab until you complete and submit the lab. In the past I have not made lab attendance mandatory beyond the beginning of lab but I have found that too many students do not budget their time well, procrastinate, and do not make any meaningful progress on the lab. Thus it is required that you attend and work on the lab during the lab period. If you have a time conflict throughout the semester (e.g., a class conflict) that does not allow you to attend the entire lab period please get an excused absence from me.

Pair Programming

For each lab you have the option of working with a lab partner. If you choose to do so, please make only one submission and make sure that the comments at the top of your .cpp files contain both you and your partner's names. If you choose to work with a partner, you should use the pair programming paradigm discussed in class in which both of you sit in front of the terminal with one person typing in the program (the driver) and the other person observing and reviewing the code (the observer). It helps to switch roles periodically (30 minutes is sometimes suggested) to keep you fresh. If you cannot complete the lab during the allotted lab time, then you and your partner should strive to find times to work together outside of the lab.

Research shows that students who choose to work together using the pair programming approach typically develop programs in less time and with fewer bugs than students working alone. For more information about pair programming, check Wikipedia's pair programming site.

For tips on how to overcome some of the logistical problems associated with pair programming, check here.

Late Labs

You can submit your lab up until 3 days after the due date but 10 points per day will be deducted from your final score.

Lab Submission Info

We will use the generic submit script: 140_submit. Run this program from the directory containing your code to submit.

Plagiarism Policy

You must write your labs alone, with one important exception: if you have a pairs programming partner, you may write labs in concert with your parter. Obviously, you may talk about your labs with the TA's and with other students, but ultimately you must write your own code. Otherwise, it is plagiarism.

A corollary of this is to protect your directories so that no one can read them. If you do all of your work in ~/cs140, then right now, do:

UNIX> chmod 1700 ~/cs140
If someone cheats off of you, chances are we cannot determine that, since file access times can be modified. In the past, when I have discovered cheating, both parties (cheater and cheatee) get punished. Protect yourself. Punishment for a cheating offense can range from a 0 on the assignment to an F in the course and my sending a letter to academic misconduct. The punishment depends on how seriously I view your transgression.

Making Your Code Readable

In the real world your program will not be a one-and-done affair like it is in this course. Instead other people may have to maintain it after you have moved on to other projects. You therefore want to always strive to make your code as readable and well-organized as possible. Two techniques that help improve the readability of your code are good comments and meaningful variable names. You will be graded on both commenting and the variable names you choose. Something like 15%.

Variable names should reflect the purpose of the variable. For example, suppose I want to save the index of the minimum value I have seen thus far in an array. I could choose a meaningless variable name like m that will convey no information to a reader. A more meaningful name would be min but it still lacks clarity. Is it a minimum value, a minimum index, or some other min?. A meaningful name would be min_index or min_index_thus_far. It certainly takes more time to think up and type meaningful variable names but it is a good habit to get into.

You should comment your code by blocks of comments at the beginning of your files, and before subroutines. Variables should be commented inline. You may also want to comment large blocks of code. You should not comment with a ``running commentary'' to the right of your code, because that is often useless, hard to maintain, and disconcerting. I have seen comments like the following:

  if (i == 0) {               /* If i equals zero */
    return;                   /* then return */
  } else {                    /* otherwise */
    exit(1);                  /* exit with a value of one */
The above is an extreme example, but don't let it happen to you.

Here's an example of what I would consider a well documented program:

#include < stdio.h >

/* sumnsquared.c
   Jim Plank
   August 23, 1998

   This program prompts for and reads a value n from standard
   input, and then calculates and prints the sum of squares
   from one to n.  It uses a for loop instead of using the 
   closed form expression.

  int n;                   /* The value */
  int sum;                 /* The running sum of squares */
  int i;                   /* An induction variable */

  /* Prompt for and read in a value of n */

  printf("Enter a value n: ");
  if (scanf("%d", &n) != 1) {
  /* Calculate sum for each value of i from one to n */

  sum = 0;
  for (i = 1; i <= n; i++) sum += (i*i);

  /* Print the final summation */

  printf("%d\n", sum);