General Instructions for Labs

Lab Sessions

  • Keep up with the assigned reading on the schedule; each lab assumes you have read the required material.
  • 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.
  • 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 or any text editor of your choice, and save it in a file named 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 (.cpp 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.

    When you log in to a linux machine on the network, you land in your home directory. Recall that a shortcut for your home directory is "~". In the file system, it happens to be at:

    /escnfs/home/YOURNETID/
    

    You will see a directory called esc-courses. It contains an entry for this course named fa-cse-20311.01 (and will later also contain one for each cse course you take from now on, if the course is also similarly set up). That folder contains two entries: dropbox and public. The former will be where you will submit your homework files; the latter will contain files that we will make available for you.

    Your dropbox directory is therefore:

    ~/esc-courses/fa19-cse-20311.01/dropbox/
    
    (which incidentally is actually at: /escnfs/courses/fa19-cse-20311.01/dropbox/YOURNETID/ )

    For each lab, you will create a folder under your dropbox directory, where you will submit your programs and files for that lab homework. Name them lab1, lab2, etc.

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

    cp prog1.cpp ~/esc-courses/fa19-cse-20311.01/dropbox/lab1/
    
    We will later learn how to create a symbolic link so as to make the above commands quite shorter.
    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.