| Lab | Due Date | Grading Guide | Status |
| Lab 1 |
|
guide | Ready |
| Lab 2 |
|
guide | Ready |
| Lab 3 |
|
guide | Ready |
| Lab 4 and sample Part 1 design document and Part 2 design help |
|
guide | Ready | Lab 5 |
|
guide | Ready |
| Lab 6 |
|
guide | Ready |
| Lab 7 |
|
guide | Ready |
| Lab 8 and design answers |
|
guide | Ready |
| Lab 9 and design answers |
|
guide | Ready |
| Date | Room |
| Monday 2:30-5:30 | Claxton 103 |
| Friday 11:15-2:15 | Claxton 103 |
Labs are due at the same time, regardless of the lab in which you are enrolled. The TA's will let you know how to submit your lab work.
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 will be required to submit design documents that describe the high level design of your program, including key observations about how you can attack the problem, pictorial diagrams of your data structures, the structs you will use, and the test cases you will consider. The key observations section should explain why you are selecting various data structures to represent your data and explain at a high-level, how you plan to solve the problem. A sample design document can be found here.
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);
}