General Instructions for Labs

Lab Sessions

  • Keep up with the assigned reading on the schedule; each lab assumes you have read the book.
  • Bring your book to lab to use as a reference.
  • The TA will make a short presentation on practical topics such as Unix and debugging.
  • Expect to finish part of the assignment in lab and then complete the rest on your own time.
  • To earn a participation point for that day, you must demonstrate that you have part 1 of the assignment working during the lab session. Show it to the TA as soon as you are done, to avoid a rush at the end of the period.

    • Coding Style

    At various points during the semester, we will touch on issues of coding style. The following are a few reminders of key points:
  • Write useful comments. Definitely put a comment at the beginning of each program, indicating your name, the class and assignment, and the purpose of the assignment. Definitely put a comment at the beginning of each function, indicating its purpose and implementation. Put a comment before any bit of code that is particularly tricky, to clarify to the reader what's going on. Commenting each line of code is unnecessary.
  • Choose meaningful variable names. In general, names of variables and functions should be obvious English names. For example, compute_average is a good name but cmpav is not so good. That said, it is common practice to use single letters for loop varibles (i,j,k), for Cartesian coordinates (x,y), and other places where there is a universal mathematical convention.
  • Indent consistently. All code within the same block must be indented the same number of spaces. We don't care whether you indent 3, 6, or 8 spaces for each block, as long as you are consistent throughout the program. Better yet, just use the program indent to clean up your code automatically.
  • Don't repeat yourself. If a fixed constant is used more than once, put it in a well-named variable and define it exactly once. If a formula is used more than once, put it in a well-named function, and define it exactly once. If you keep typing the same code many times with a simple variation, put it inside of a loop. And so on...
  • Validate input. Any time that you accept input from the user, there is a very good chance there is something wrong with it. Always check to see if the input is valid. If not, display an appropriate error message.
  • Use global variables sparingly. Generally speaking, global variables should be avoided. It is better to pass information through function parameters, so as to make it clear how data is used throughout the program. If you decide that a global variable is essential, then you should clearly justify its use in your lab report.

    • Lab Report

    For each lab, you will create a short report that explains the creative portion of the lab. This will help the grader to understand what you have written, and assure us that you did it yourself. Don't try to impress us with flowery language, just get to the point with a plain, clear explanation. Take care to organize your thoughts into paragraphs with correct grammar and spelling. The first lab report will be short (a few paragraphs at most) but later reports will require increasing detail.

    This lab report should explain the following things:

  • What your program is meant to do, from the user's perspective.
  • How the program is structured, from the programmer's perspective. If there is an algorithm involved, give the pseudo-code for the algorithm.
  • How you evaluated the program for correctness. Did you verify that it produces correct results? If so, give examples. Are there any cases where it produces incorrect results? If so, explain why and give an example.
    • Please write your lab report in plain text using nano and save it in the file report.txt: 
    nano report.txt

    Turning In

    All submissions will be done electronically, so as to save a few trees, and make life a little easier for the graders.

    Copy all of your source files (.c and .h files), the lab report (report.txt), and anything else specifically requested into your handin directory. Do not turn in the executable programs: that wastes space and we are going to compile your code anyway.

    Your handin directory is: 

    /afs/nd.edu/courses/cse/cse20211.01/dropbox/NETID/labN

    For example, to copy prog1.c to the handin directory for lab1: 

    cp prog1.c /afs/nd.edu/courses/cse/cse20211.01/dropbox/NETID/lab1
    (Hint: type in one command, then use the up-arrow to modify the command, and then repeat it.) You can verify that your files are handed in by running the following command: 
    ls -l /afs/nd.edu/courses/cse/cse20211.01/dropbox/NETID/labN
    If you find a mistake after turning in but before the deadline, you can update your submission by simply copying the necessary files again. You are free to turn in assignments multiple times before the deadline expires. It would be a good habit to turn in an incomplete but working assignment on a daily basis. Thus, there is no excuse for failing to turn in an assignment: everyone should turn in something long before the deadline.