| Lab | Due Date | Grading Guide | Reading Assignment |
| Lab 1 |
|
guide | none |
| Lab 2 |
|
guide | none |
| Lab 3 |
|
guide |
|
| Lab 4 |
|
guide | Kernighan & Pike: Ch. 1 |
| Lab 5 |
|
guide | Kochan: Ch.18, pp 395-409 (gdb)--you should have read this portion for a previous lab but it is good reference material for this lab as well |
| Lab 6 |
|
guide | None |
| Lab 7 and design document |
|
guide | Kernighan & Pike: pp. 139-147 |
| Lab 8 and design document |
|
guide | valgrind |
| Lab 9 |
|
guide | none |
| Lab 10 and design document | See lab write-up for what is due after one week and what
is due by the end of the lab
|
guide | none |
| Date | Room |
| Monday 2:30-5:30 | Claxton 103 |
| Monday 2:30-5:30 | Claxton 105 |
| Friday 11:15-2:15 | Claxton 103 |
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.
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.
You must write your labs and homework assignments alone, with one important exception: if you have a pairs programming partner, you may write labs (but not homeworks) in concert with your parter. Obviously, you may talk about your labs and the homework assignments with the TA's and with other students, but ultimately you must write your own code, your own homework solutions, and your own outlines. 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 ~/cs140If 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.
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.
*/
main()
{
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: ");
fflush(stdout);
if (scanf("%d", &n) != 1) {
exit(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);
}