Coursework Basics

This page contains information that is common to all the exercises and programming assignments, and which you may find useful as you work through them.

Getting the assignment’s files

Every assignment has a series of files you will need to complete the assignment, including some skeleton code as well as the automated tests for the assignment.

So, before you can start working on an assignment, you will need to get those files into your git repository (please note that it is important that you complete Setting Up Your CMSC 15200 Directory section of the Remote Linux Lab to get your repository set up properly.

To get the files for a programming assignment, change to your cmsc15200-win-21-username directory (where the string username should be replaced with your username) and then run the following commands:

$ git pull
$ git pull upstream master --allow-unrelated-histories

The first command just ensures that your local copy of your repository is in sync with the server. The second command is the one that actually fetches the instructor-provided files. Instead of pulling from your own repository, it pulls from a special “upstream” repository set up by the instructors.

If, after running git pull upstream master you are taken to a screen saying “Merge branch…”, see this entry in our Git FAQ.

Files for the exercises and programming assignments will appear in a se/seN or pa/paN directory, respectively, where N will be 1, 2, 3, etc. (i.e., se1, pa1, se2, pa2, …). The directory will include a README.txt file with a description of the files contained in the directory. Make sure to always read this README.txt file.

Please note that it is always good practice to run git pull upstream master before you start working, as this will fetch any updates to the instructor-provided files. For example, we may occasionally update files if we notice bugs in our code, add helpful new test cases, etc.

Directory structure

The directory structure will be the same for all of the assignments. The assignment directory will contain:

  • README.txt - a file that explains the contents and purpose the files and subdirectories in the assignment directory

  • Makefile - a file that you will use with make to compile your code

  • bin - a subdirectory that will be used to hold the binary executables

  • include - a subdirectory that contain the include files (.h) for the assignment

  • src - a directory that will contain the source code files (.c) for the assignment. You will do most of your work with these files.

  • tests - a directory that will hold the automated test files

Using git

Once you’ve fetched the assignment’s files, you can proceed as described in the Git Refresher section of the Remote Linux lab: work on your code and then run git add <filename> for each file you change, followed by git commit -m"some message" and git push to upload your changes to the server.

We suggest you add/commit/push every time you complete a specific piece of work, or once you’re done working for the day, so there will be a backup of your code in the Git server. Your commits should describe the work that you did as part of that commit, and should look something like this:

  • Finished Task 1

  • Made progress on Task 3, but not yet done

  • Fixed bug in Task 2. All tests pass now!

You should also make sure to run git pull and git pull upstream master before you resume work to retrieve the latest files. This discipline will guarantee that you always have the latest version of your code, no matter which machine you are using. Also, it will be easier for us to help you recover from git problems if you consistently push updates to the server.

That said, you should avoid using Git as a mechanism to synchronize your code across multiple computers. More specifically, let’s say you’re working on your own computer, and need to upload your files to a CS server to run the tests. You should not do this by pushing your code to the Git server from your computer, and then pulling it from the CS server.

In other words, if you find yourself frequently committing code with messages like “Uploading to CS server”, “Changing file to try on CS machine”, etc. and doing this multiple times while you’re working on your code, this is not how version control systems are meant to be used. A commit should represent a meaningful change in your code, and should not be used as a mechanism for copying files to another machine.

Instead, we recommend that you set up Visual Studio code to edit your files on the CS Linux servers remotely. See Working Remotely with Visual Studio Code and SSH for instructions. This way, you can do your work on the CS Linux servers and test your code without having to move it back and forth between computers.

Style

Following a consistent style is important because it makes it easier for others to read your code; imagine if you were collaborating on a large software project with 30 other developers, and everyone used their own style of writing code!

In this class, we will be adhering to the CS Style Guide. We expect you to use good style (that is, style that matches this guide), and will take this expectation into account when grading.