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
directory (where the string
username should be replaced with your username) and then run the
$ 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
pa/paN directory, respectively,
N will be 1, 2, 3, etc. (i.e.,
The directory will include a
README.txt file with a description
of the files contained in the directory. Make sure to always read
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.
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
maketo 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
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
commit -m"some message" and
git push to upload your changes to
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.
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.