CS360 Lab Homepage

FAQ about Labs

Where are lab writeups and due dates?: For all lab writeups and due dates please refer to Dr. Huang's CS360 labs!
Where can I see my grade on a lab?: All lab grades will be posted on Canvas.
How do I submit my lab?: All labs will be submitted via Git repository rather than a submit script. Please see the Git Guide for a walkthrough on using Git. This guide covers pretty much everything in Git, but you really only need chapters 1 & 2 for this class. Dr. Stephen Marz has also written a guide to Git that will cover the things you need for this class.
We will use the EECS-hosted Gitlab instance to host your Git repositories in this class. We also provide a list of steps you can follow each time you need to make a repository for a lab. The only thing you need to do to submit a lab on time is to have it in the corresponding Git repository by 11:59 PM on the due date.
What do I need to do if my lab is going to be late?: If you have to submit a lab late, make sure you follow the procedures for late submissions!
What files should I submit as part of my lab?: Only submit neccesary files as part of your lab. You will lose points if you don't. Be sure to get rid of any .o files, executables, or other non-essential files in your repository. If you don't know if a file should be submitted, ask a TA.
You must also submit a makefile with every lab! It must have a clean function (i.e., typing make clean should result in the removal of any .o files or executables. Please see this Makefile tutorial and Dr. Plank's lecture notes on makefiles. If you need further help writing a makefile, ask a TA.

Lab Grading

Early Submission:

Early submissions grant a 5% bonus per day (max of 15% for 3+ days early) to your grade on that lab. Please note that this is a 5% bonus and not a bonus of 5 points. If you wish to submit your lab early, please email Hunter with the subject line "[COSC360] Early Lab Submission" along with the commit hash of the commit that you want us to consider as your submission. We will consider your submission to be on the day that you email us and not on the day that the commit you specify was made.

Short Code Competion:

If your submission is within the top 30% of students with the fewest lines of code, you will recieve a 10% bonus to your grade on that lab. Keep in mind if you submit your code with all whitespace removed you will be docked on the code quality section of the rubric.

Late Policy:

Late submissions incur a 10% penalty per day. All labs are due by midnight (11:59PM) on the due date. No exceptions can be made, unless an extension was given via the class mailing list or compelling reasons such as significant illness exist.

One-Time Waiver:

Every student is entitled to a waiver of the late submission penalty for one lab assignment. It must be submitted before the final exam. Please use your lab waiver wisely.

Lab Completion:

All lab assignments must be completed to a degree deserving more than 60% credit, be it a late submission or not, for a student to pass this course. If a student fails to meet this requirement by the time the final exam is held, the student automatically fails this course!

Mistakes and Appeals:

If you think a mistake has been made, contact your grader for that lab. Either explain why you think a mistake has been made or arrange a time to meet with them.

All grade appeals must be initiated within ONE WEEK after receiving your lab grade. It is not necessary that the grade appeal be taken care of within that week, but you must have at least contacted your TA and expressed your desire to appeal your grade.

Rubric:

Grading on labs will slightly vary depending on if we test for memory leaks or not in that lab:

Testing for Memory Leaks

Gradescripts: 80%
Memory Leaks: 10%
Code Quality: 10%

Not Testing for Memory Leaks

Gradescripts: 80%
Code Quality: 20%

Gradescripts: You will earn a percentage of the 80 points equal to whatever percent of the gradescripts your code passes.
Memory Leaks: If a successful run of your program leaks any memory, you will lose this full 10%. We say successful because not freeing memory when an error would cause your program to exit isn't a leak, the OS will reclaim it on program exit.
Code Quality: This includes everything covered in the Code Guidelines section below.

Code Guidelines

All lab source code must adhere to the following style guidelines. If it doesn't, points will be deducted or (in extreme cases) that lab submission will not be graded until a clean version is submitted. The late policy still applies if this is the case. Please feel free to see any of the TAs if you have questions or are unsure if your source code is conforming properly.

Whitespace

Use whitespace to make your code easier to understand. We will not grade you on any particular formatting style, but our personal recommendation is a 4-space indent for each nesting level.

Variable Naming

Use descriptive variable names. i, j, and k are ok for iterators, but generally try to avoid 1-letter variable names outside of that. For a general rule: If you get someone else to read your code and they have to figure out or ask what information a variable is representing, you should give it a better name.

Comments

Use block level commenting. Your comments should give an overview of your code and provide additional information that is not readily understandable from the code itself. It is not neccessary that you comment every line in your code. When documenting a program, say only what needs to be said without leaving important things out. We should be able to read only your comments and get a general idea of what your code is doing and how it is doing it.

Function Documentation

All functions need to have a header that includes the following information (example below):

Function Name
A brief description of the what the function is doing
Parameter names and brief descriptions
Brief descriptions of the return values of the function and when they are returned


					/**
					* @name add_numbers.
					* @brief Adds two numbers, stores the result in a pointer, and then returns the result as a double.
					* @param[in] x The first number to add.
					* @param[in] y The second number to add.
					* @param[out] z Pointer with result stored.
					* @return The result of the addition cast to a double.
					*/
					double add_numbers(int x, int y, int* z) {
					    *z = x + y;
					    return x + y;
					}

Modularity / Function Decomposition

Most of your COSC360 labs are going to require more lines of code than in previous courses, so it is important to break your code into functions. A function should perform a specific task or a collection of small highly related tasks. Do not stuff all your code into the main function. Doing so will make your code harder to read and debug when you run into a problem.

Error Checking

We expect you to implement robust error checking into every lab. The following things will be checked with our grading scripts.

Value of command line arguments
Number of command line arguments
Return values of system calls

If an error occurs, be sure to output a meaningful error message to stderr and have your program exit gracefully.

Global Variables

Use global variables appropriately and only when neccesary. This means that you should not under any circumstances make all of your variables global. In general, if using a local variable is possible, use it.

CS360 -- Systems Programming

Jian Huang --- Fall, 2022

Teaching Assistants:

FAQ about Labs

Lab Grading

Testing for Memory Leaks

Not Testing for Memory Leaks

Code Guidelines

Memory Leaks

Ed Discussion