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 the introductory labs to learn the basics of Linux and Git before you start working on your first exercises).

Doing this will involve running a series of commands, and each assignment will include the exact commands you need to run for that assignment. If you’re ever unsure of what these commands do, please take a look at the upstream section of Introduction to Git

Once you’ve fetched the files into your repository, take into account that it is always good practice to run git pull upstream main 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.

Using git

Once you’ve fetched the assignment’s files, you can proceed as described in Introduction to Git: 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.

At the start of the quarter, we recommend that you simply work directly on a CS environment (e.g., on CSIL or by using the Virtual Desktop system). Once you’ve developed more comfort with using Linux, you can switch to working on your own computer, and using SSH to copy files from your computer to a CS server. You can find instructions on how to do this on the CS Techstaff’s website (see “File Transfer” in their Remote Access page). You can also set up you code editor to this automatically for you (and we provide instructions on how to do this with Visual Studio Code)

Signing up for a Team Repository

Some assignments will allow you to work in pairs. The process for requesting a repository is a little different in these assignments, and each person in the pair will play a different role. We will refer to each as Person A and Person B. Each has a different set of steps to complete. Please note that Person B must not complete their steps until Person A is done with theirs.

Person A: Follow the invitation URL for the assignment. You may be shown a list of existing teams, but you should not select any team on the list. Instead, you must create a new team called A-B-N, where A is your CNetID, B is Person B’s CNetID), and N is the assignment number. For example, if Person A is amr and Person B is borja and they are working on PA #4 together , the team name will be amr-borja-4. Once the team is created, go ahead and accept the assignment.

Person B: After Person A has completed their steps, go ahead and follow the invitation URL for the assignment. Your team’s name (A-B-N) should now be on the list of possible teams. Select your team (A-B-N) from the list and accept the assignment.

Once this process is finished, you will both have access to the repository. However, please note that the process to initialize the repository will also be different for each person (the programming assignments will provide concrete instructions on this)

Using IPython

It is important to experiment with library functions and try out your own functions by hand in ipython3. When starting IPython, you should make sure to always enable “autoreload”:

$ ipython3

In [1]: %load_ext autoreload

In [2]: %autoreload 2

The commands %load_ext autoreload and %autoreload 2 tell ipython3 to reload your code automatically whenever it changes. We encourage you to use this package whenever you are developing and testing code.

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.

One way to catch style issues in your code is by running pylint, which can alert you to a number of style issues in your code. For example, to run pylint on your PA #1 code, just run this from the Linux terminal:

pylint sir.py

Please note that we do not rely exclusively on pylint to review your code’s style, and that pylint may flag issues that are not covered in our style guide (and that we will not be checking for when reviewing your code). However, it can be a useful tool to quickly spot things like lines that are too long, or inconsistent indentation.

Pylint will also run as part of the Gradescope autograder, but you should ignore the “score” that pylint reports (the line that starts with Your code has been rated at). That score does not factor into our grading in any way, and is not part of the automated test score. It is simply a metric that pylint reports to give you a sense of how good your style is.

Working in a pair

Working with a partner can be a great experience, and one that more closely resembles the way in which software is developed in real projects, but working with another person can also be challenging. We encourage you take a look at the Working in Teams page of the CS Developer Guide, but please note that you should skip the “Using Git Effectively” section, as that section covers advanced techniques that are not relevant in this class.

If you are working in a pair on an assignment, you will be able to request a repository that both you and your partner will have access to (instructions on how to do this will be included in the programming assignments that can be done in a pair).

When you work in a pair, it is very important to be disciplined about synchronizing your local copy of the repository with the server before you start working and again when you are done. It is very easy to find yourself with a nasty merge conflict, if you do not communicate effectively with your partner and if you let the code in your personal copies of your shared repository diverge significantly.

See the FAQ for advice on how to deal with merge conflicts. If you run into a merge conflict, you may also want to review the merge-conflicts section of Introduction to Git.