CS 11

Homework Guidelines

Table of Contents

Overview

We know that a lot goes into a CS11 homework assignment, and much of it is unfamiliar to students who are new to coding at Tufts. This document is meant to give a general overview of the homework policies and help you get accustomed to the course.

All homework assignments will go out and are due as described on the course calendar. Any last minute updates about assignments or due dates will happen on Piazza

Tips

Getting Started

The first step for any assignment is to log in to the Linux server from the outside world, make a directory and copy or create some files. Detailed instructions on this process can be found in the lab0 spec.

If you are creating new files, you can do so using touch filename in your terminal, or through Atom. If you create a file on Atom, you must upload manually to the department servers by right-clicking on the file then going to Remote-Sync-PRO > Upload. This puts the files you made on Atom onto terminal/the department servers. If you make or copy files in your CS11 directory in terminal/through the department servers, you will need to go to your CS11 directory in Atom, right-click on it, then hit Remote-Sync-PRO > Download, to bring it to Atom. The gist is upload on Atom sends your file or directory from to terminal/the department servers so you can run it, submit it, etc. Download on Atom brings something from terminal/the department servers to Atom so you can edit it in the text editor. Note that Atom will not show an empty directory, so if you make a directory in terminal/the department servers, you either have to put a file into it before downloading to Atom, or you can make a directory in Atom that has the same name as that you made in terminal/the department servers, and the two will be linked.

Written Questions

Your homework assignments will include programming components and written components. The written components will vary depending on the assignment, but your written.text should always clearly number and answer each question, and have a header that includes the assignment, date, and your name. Don't get fancy with the characters, or try to copy and paste from Word or other programs. They will often paste strange "invisible" characters that can create issues when you submit your file.

As with all other files, your written.text should follow the 80-column rule. You will have to do this manually by typing an explicit return at the end of each line (resizing the window does not change the length of a line in the file). Also, do not let let your editor insert tab characters in your file: each indentation should be 4 or more space characters. This ensures your text and code will look the same to the grader as it does to you, regardless of their tab settings.

Pseudocode

A common written question involves writing pseudocode for one or more of the programming assignments. Pseudocode is a written description of your algorithm that should not involve any programming syntax. It should clearly explain how your program should run and what steps it will take to solve the problem, but should not be the code itself. Think about how you might explain how your code works to someone with no programming experience. You should always write your pseudocode before coding, because it will help you write the code itself. Your pseudocode does not need to match your final program, so don't worry about editing it if you realize the original plan does not work.

Pseudocode should be in bullet points, and list the variables you plan to use along with their types and what they represent. You should also discuss any decisions your program might make, what condition it depends on, and how your program will respond in each circumstance.

Example 1: computing the number of minutes in a given number of years

Example 2: Decide if someone can ride a rollercoster based on height and if they are with a parent

You can read more about pseudocode on these lecture slides.

Testing and Debugging

Write a little, compile a little, run a little, and repeat! It's better to submit a small program that works than an ambitious one that has syntax or other errors. The best programmers never get too far into their coding before they test their program and make sure everything is working. Write a little bit of code, run it, and go back to writing. I compile at least every time I take a few minutes to think or every 5–10 lines of code I write, and usually I test the code at that point, too.

Indeed, there often are very useful tests you can do on a program that's only partly written. Maybe you think you can handle simple inputs (positive numbers, perhaps), but not more complex cases? Test what you've got! Try some positive numbers. Get that much working. We even have a name for this practice in computing: incremental development. If you write the whole thing and then test, well the problem could be anywhere. It will be hard to find! If you test incrementally, then there's a good chance that your bugs will be easier to find!

We may give some testing infrastructure, sample inputs and outputs, and/or a reference implementation for assignments to help you test. However, designing and writing a working program is your responsibility, and passing the tests we give does not guarentee full credit.

How to Test

A common question we get asked is how to start testing. Spend some time trying to break your code and thinking of weird interactions that could possibly happen. Try to do this at every step, testing each function or piece of the puzzle as you write it. This process will depend greatly on the specific problem, but there are a few examples below.

Before submitting, you should always rerun all the tests you wrote to make sure you didn't accidently break something when fixing another bug.

11test

So you have a general idea on testing, but how do you know you've got it right? Or, in CS 11 terms, how do you know you'll get full credit? You don't really. There's always a chance you've missed something, but remember: to get full credit you must exactly and completely meet all of the specifications in the written instructions.

If the instructions say that a prompt should be Enter a number: then you don't want to say Give me a number: or even Enter number:. Include the colon (:) if we ask for one. Start new lines (using endl) where the instructions say to, and not when they don't. Get all of that right as well as the functionality, and you will receive full credit.

That sounds like a lot to keep track of! To take some of the pressure off, we have a tool called 11test for some of the early assignments that you can use after you've written and compiled your program. Instructions using 11test on a given assignment will be included in the spec.

11test will run your program one or more times, possibly on different inputs, and report any problems that it finds. Read the output carefully; it will tell you what inputs were used and how your program responded. (You must have run use comp11 before trying this; if not the 11test program will likely not be found.)

Q. If my program passes all 11test tests, will I get full credit for my submission?

A. Not necessarily. Making sure that you have correctly followed all the instructions is your responsibility, but 11test will help you find some common problems. For HW1, if 11test reports no problems then you can be reasonable confident that at least the format of your prompts and of your output is good enough for full credit. For later assignments we will leave more of the format and other testing to you.

Q. If my program fails one or more 11test tests, will I lose credit on my submission?

A. Almost surely. Indeed, as described above, mistakes in things like formatting can cause you to lose credit on every test we run. You should try hard to fix any errors that 11test finds. If you need help or don't understand why you are failing, come to office hours. TAs are more than happy to help.

Q. I'm really worried: I've spent a lot of time trying to fix bugs and I just can't get things to work. What should I do?

A. Well, we hope you're getting help from TAs etc. along the way, but programming can be difficult. Even very good students don't always get every program to work well. Do not let this discourage you! Typically you can get zero or low credit on a few parts of a few homwork submissions and still get an A or even an A+ in CS 11. You definitely should submit whatever you have, as (a) you may get significant credit for the parts of the program that do compile and run and (b) we also read your code to see what you tried: so you can get some credit for writing a promising submission that you never could quite get to work at all.

Style Guide

Along with how well your program functions, we also evaluate how your code is organized and whether or not it is written with good style. Remember: Programs are written for people to read. You are communicating your algorithm to a human reader, the grader in this case. Make sure your programs are beautiful, clear, and well-documented, in addition to being correct! Lines should be under 80 columns. There should be spaces around all operators (including =). Like the other lines your programs write, the last line should end with a newline (which in C++ you get using endl as you do on your other output lines), unless a particular assignment asks you to do differently. And don't forget comments at the top of each file describing that file and giving your name and the date. Think about your code the way you would an essay; you write essays with a heading, consistent margins and spacing, and correct punctuation. An essay with good content but horrible style would not receive full credit, so neither will code that works but disregards the style guidelines.

You are responsible for reading and understanding all the guidelines in the CS11 Style Guide.

Each week we give out a few "pleasure to read" points to students who have written code that is well commented, and just all around beautiful! To get the points, your code must follow all of the rules in the CS 11 style guide (linked above), must bring the grader aesthetic pleasure and have a strong sense of intellectual clarity. Only a few students a week are likely to get it. Work that is awarded the "pleasure to read" points is usually worthy of an A+ grade. Keep an eye out for this on your Gradescope report!

Projects

A project is basically a two week homework assignment on a bigger problem. Projects are split into parts to make them more digestable, but over the two weeks, you will build a big and interesting program. Past CS11 projects have included a database that tracked gene mutations, card and video games, and a simulated fish tank. We hope that you can come out of a project excited about an interesting program you've made.

A project is broken up into phases, with each having its own submission and being graded separately. Most of the overall grade is from the final submission. Specific weighting can be found in the project spec. There is more information on how project grading and submission in the sections below.

Grading

40% of your CS11 grade will come come from homework assignments which consist of weekly assignments and one or more projects. All homeworks are normalized to 100 points, and weigh equally besides projects which count as two normal homeworks. The lowest homework score may have its weight reduced, e. g., it may count only half as much as other assignments.

Programs will be evaluated for functional correctness (FC) and for style and organization. The weight of an assignment can be anywhere from 60–80% FC, with the remaining grade coming from style.

Functional correctness will be determined by an automated system that will run your program on various test inputs. Your program must compile on the department servers to receive any functional credit! The best way to ensure credit is through thorough testing, which is described in detail above.

Style and organization is graded manually by the staff, and will depend on having good coding practice, logical organization, and generally adhering to the course style guide.

Regrades

It is important that you understand any evaluation of your work. Therefore, you are always welcome to ask for an explanation of a grade you received.

Sometimes, we make mistakes, of course, and we want to get things right. If the mistake is in your favor, you don't have to do anything: it's your lucky day. If you feel there was an error that you have been deducted for, first think very carefully. If it is our mistake, then make a regrade request.

All regrade requests (whether for exams or homework) must be submitted via Gradescope within one week of the assignment grades being released. In cases where it is not immediately obvious how to submit a regrade request for a particular component of an assignment, it is always fine to submit the request on the first problem of the assignment.

A regrade request may or may not result in a new grade being assigned. The new grade may be higher or lower than the original grade.

Late Assignments

Homework is expected to be submitted on time. However, we recognize that the exigencies of college life occasionally thwart a deadline. In such circumstances, there are two types of extension:

  1. Late tokens are for short-term issues like a routine cold, sore throat, etc. A late token grants you a 24-hour extension on an assignment. Each of you has 5 of them to use over the course of the semester. A maximum of two tokens can be used on any single assignment; submissions more than 2 days late will not be accepted and will recieve a 0.
    Using a late token requires no action on your part. Our grading scripts will automatically check the date of your submission and deduct the appropriate number of tokens.

  2. Dean-supported extensions are only for cases of serious illness, family emergencies, or other unforeseeable severe difficulties. In these special circumstances, extensions are granted after we receive a request from your associate dean. No extensions are granted merely on the basis of a student request. Please do not ask the deans to support you if you are out of tokens or don't want to use tokens or if you simply mismanaged your time. Of course, if you do have a serious illness or family emergency, then definitely contact the dean so they can coordinate with all your instructors.

Token Summary:

Collaboration and Academic Integrity

Everyone should read the Tufts policy on academic misconduct located on the student affairs office website: https://students.tufts.edu/student-affairs/student-code-conduct/iv-policies-regarding-student-behavior.

As stated in the tips above, it is important to note that all assignments can and should be done ONLY using tools and concepts that have been covered so far in the class. If you are unsure how to approach a problem, you should not begin by searching for an algorithm or solution online. Rather, come to office hours. If you have any doubt about whether a concept or tool can be used for a given assignment, ask the staff on Piazza. You will not get credit for work that includes tools or concepts outside the scope of the assignment.

Homeworks will be comprised of two components, a written component and a programming component. For each of them, we have slightly different policies about which forms of outside help and collaboration are acceptable:

Written questions

The goal of our written problems is to give students practice at finding pieces of information that they have not expressly been given in class and lab. This skill allows you to eventually function independently as a programmer, and is critical for all computer scientists to master.

As such, students are expected to find the answers to written problems themselves. They may not confer with their classmates, and may only minimally query the TA staff. From there, however, any means of finding an answer that does not explicitly contradict the written instructions is fair game. Students may search the internet, consult their textbook, write test programs — anything, as long as sources are cited in the write-up.

Programming

Both your classmates and the internet at large can be invaluable resources, so long as they are used according to the following policies:

  1. You may search the internet and talk to other students about general programming concepts and C++ syntax, but not about assignment-specific code or strategies. For example, it is fine to ask “How do you structure a while loop in C++?”, but it is not fine to ask “How do you write the function for HW 3 in C++?” Assignment-specific questions should only be posed to the course staff.
  2. Use English. Use pictures on white boards. However, you should never be looking at another student's code and no one outside of our course staff should be looking at your code. If a TA sees you doing this, it will be reported.
  3. Only submit code you can explain. We reserve the right at any time to ask you to explain a piece of code that you submitted. If you cannot explain the code, then we will have no choice but to assume that it is not your work.
  4. Do not plagiarize code! You must not submit code that others wrote or that you wrote for a previous class (or previous iteration of CS 11).

Suspected academic integrity violations are forwarded directly to the Office of Student Affairs. Their sanctions range from horrible to inconceivably horrible. It's not worth it.

Mark A. Sheldon (msheldon@cs.tufts.edu)
Last Modified