Homework will be assigned roughly once per week. It will be graded, and require substantial work. The average student should expect to spend about 15 hours per homework. Homeworks will typically contain a mix of programming exercises and "theory" questions about data structures and their implementation. Roughly 3 assignments will contains pieces that contribute toward a class project, which is to build a simpler version of a microblog site from scratch. As the project progresses, students may find it necessary to revisit and improve their earlier solutions, so good coding practices and documentation are strongly encouraged.
Each student will receive a private code repository on the course's GitHub Organization to use it for the development and submission of all assignments. You will be using the git source code management tool to maintain your homework code.
|HW01||Course Overview and Recursion||Fri. May 26, 2017 @ 11:59PM (PST)||Submit|
|HW02||Linked Lists and Stacks||Fri. June 2, 2017 @ 11:59PM (PST)||Submit|
|HW03||Copy Constructors, Operator Overloading and STL||Fri. June 9, 2017 @ 11:59PM (PST)||Submit|
|HW04||Project, Part 1 (Twitter)||Sun. June 18, 2017 @ 11:59PM (PST)||Submit|
|HW05||Project, Part 2 (Qt)||Tues. June 27, 2017 @ 11:59PM (PST)||Submit|
|HW06||Project, Part 3 (Sorting & Connected Components)||Tues. July 5, 2017 @ 11:59PM (PST)||Submit|
|HW07||Map and Set Implementations||Wed. July 12, 2017 @ 11:59PM (PST)||Submit|
|HW08||Project, Part 4 (Heaps and Maps)||Sun. July 16, 2015 @ 11:59PM (PST)||Submit|
In order to properly submit your assignment, please follow the course submission instructions.
Grading Weights and Scale
The following point structure will be used in determining the grade for the course. Your final grade will depend solely on your own performance, graded according to the scale given below.
Class participation and attendance is strongly encouraged, but will not be enforced or affect grades directly. (Experience shows, however, that attendance and participation correlate highly with success in classes.)
The final grading scale is given below. The meaning of this grade scale is the following: if the weighted average (with the weights given above) of your percentages is above or equal to the given one, you will get at least that grade. As an example, if your weighted average is 79.97%, your grade in the class will be B+. Notice that this means that we do not round percentages up.
We will guarantee that you will get at least the grade indicated by the following scale. At the end of the semester, we may decide to lower the scale if the exams were more difficult than intended.
For each assignment, a precise time will be specified (usually at 11:59.59pm) on the due date. Submission must be made correctly via your github account. Each student has 4 grace days they can use over the course of the semester. A maximum of 1 grace days can be used on a single assignment. Once you have used your grace days, any late submission will not be accepted and graded as a 0.
To use a late day you MUST follow the submission policy outlined in our late submission instructions to alert the course staff to fetch your late submission. Following instructions is critical, so failure to follow the submission policies may result in a score of 0.
We will work hard to post HW scores and feedback within 1 weeks of the homework's due date. Exams will typically be graded within at most a few days of the exam date.
Any disputes with posted grades must be resolved within 1 weeks of the score posting. (If your schedule does not permit a detailed request within 1 weeks, you should register a short note that you plan to dispute, and then submit the dispute when you are ready.) Notice that any regrade request will result in us trying to give the fairest possible grade to you, which could be higher or lower than the one you received originally.
To raise an issue with your exam score, you should come to the office hours of the professor teaching your section. If you cannot make posted office hours, schedule one by e-mail. The TAs will not be allowed to grant regrades on exams.
Since we want to be able to make sure we can address all of your homework-related concerns as easily as possible, please follow the below policy for creating homework regrade requests:
- You will receive a grade report for your homework or project on GitHub.
- If you have questions, you should assign your grader to the issue, and then describe your questions in the comments for this issue.
- If the grader and you cannot resolve the issue, the grader will reassign the issue to one of the TAs.
- The TA will then review your homework and make any necessary adjustments, up or down.
Final settlement will be, if necessary, decided by the professors.
Homework Grading Policies
For each assignment, a precise time will be specified (usually at 11:59.00 pm) on the due date. Submission must be made correctly via your github account. After you believe you have submitted, you should always clone your repo into a new folder and make sure everything you think you submitted was cloned into this new folder. Then compile your code in this new folder and run it to ensure we will also be able to compile and run your code.
We will grade your assignments using gcc/g++ at the command line in the virtual machine we provide for the course. You are free to use other compilers or IDEs to develop your code, but in the end, it has to work with g++ in the virtual machine. You probably want to test that it does before submitting.
Each homework assignment generally asks for a set of features to be implemented in C++. It also usually asks students to specifically either use or not use some STL classes. Based on these requirements, each assignment is going to have its own grading rubric. We also have a general rubric which you need to consider for all assignments; this captures issues that will be common to most of your projects, like quality of your code.
Percentages are for the entire assignment, not just the points of a subproblem.
- Up to 5% deduction for using global variables inappropriately or extensively in your program.
- Up to 5% deduction if your code compiles with warnings. It depends on the number of warnings and their severity. In order to see the compiler warnings, you need to compile with the -Wall switch. For example g++ hw1.cpp -Wall -g -o hw1. If you believe the warnings are unavoidable document it in your README file.
- Up to 10% if you do not use command line arguments correctly (hard code or use cin).
- Up to 10% deduction for extra
cerrdebug statements beyond the specified output requirements
- Up to 3% deduction for each compiler error depending on the severity of mistake.
- Up to 10% deduction for bad Makefile (once Makefiles are taught).
- Up to 20% deduction for bad coding practices, code organization, indentation, naming, code file and header separation, code documentation, throwing non-exception types, etc.
- Up to 10% deduction for repo organization, garbage files in repo, folder organization, repeated code files, missing data files, missing README file, etc.
- Up to 10% deduction if your program is testable but crashes during execution or is considerably slow. Depending on the nature of the assignment, you may lose more points if your program is slow or not scalable.
- Up to 10% deduction if your program has memory leaks or any other memory errors including invalid reads/writes (e.g., out-of-bounds accesses)
- If one of the features of an assignment is not testable because it has major compile errors, you will likely lose at least half its points in addition to other coding mistakes. For example if we cannot test one of your data structure functions because it is missing the UI section (main function) or it has major compile errors, then the best we can do is to look at your code and see if it would work or not. In this scenario, we can give you at most half the points for that data structure function.
- Similar to the previous rule, if your project is missing a key feature such that testing many other features depends on it, you will likely lose a lot of points. For example, imagine that your assignment is supposed to read data from a file and then process. If you finish the processing part and leave out the file I/O part, you are making it very difficult to test your project. If you want to leave out the file I/O (maybe because you do not have time), change your main function so that it generates some data (like an initial array) just to test the rest of your assignment. This actually makes it easier for yourself to test your assignment as you build. If you want to learn more about this, look up unit testing.
Multiple choice problems
- If you miss 1 on a problem of several possible answers you get 50%
- If you miss more than 1 on a problem with multiple correct answer you get 0
- If you miss the 1 right answer (if there's only 1 correct answer) you get 0
The official language on academic integrity is on the syllabus . Here is a little more clarification.
Practically speaking, it is important to be able to seek out helpful information and collaborate, yet it is clearly wrong to pass off work done (even just in part) by others as your own. Navigating these two principles can be tricky. However, notice that only you are responsible for understanding what is allowed, and what is not. Cheating can and does occur which is neither malicious nor intentional. Knowledge is power!
When in doubt whether some behavior you are considering is appropriate, feel free to consult with us (course staff) before engaging in it. As a general guideline, imagine that your professor is looking over your shoulder, but can't read your mind. Would it look to him like you're legitimately seeking to understand things, or trying to get a better grade than your own work warrants? That should guide your behavior. Here is a list of some particularly common things, with an explanation:
- Asking other students for hints or discussing high-level ideas. This is clearly OK.
- Having other students look at your code and help you discover mistakes. This is dangerous: if the other student intentionally or accidentally copies from you, there would be negative consequences for both of you.
- Asking course staff (instructor, TAs, CPs) for help, ideas, having them look through code, etc. Clearly no problem; if you are asking for too much help, we will simply not provide that much.
- Copying code or test cases from other students, even if you subsequently edit, improve or change them. Clearly not OK, even if you intend to understand the code or inputs before submitting them as your own. This is most definitely plagiarism! We will run the MOSS software on all submissions in the class to detect instances of copying.
- Copying test cases from other students or Piazza when test cases are not graded. This is OK, since it serves to teach you something, and there is no risk that you will get points for the work of other students.
- Sharing your code or test cases with your classmates. Don't do this! We have had several cases of trusting friends getting into trouble because their "friends" submitted code as their own. If a "friend" pressures you to share code or inputs with them, they are not your friend.
- Looking at other students' code or test cases (before having finished your own). This is dangerous. If your code or test cases ends up resembling the other student's very closely, then it is cheating. To avoid accidentally cheating, we recommend the failsafe measure below.
- Looking up concepts, syntax, and basic instructions on how to deal with the topics online. This is clearly OK, as you are learning.
- Looking online for solutions to specific homework questions, such as copying code from Wikipedia and other sites. Clearly not ok, even if you subsequently edit them. You are trying to use the work of others instead of your own. Clearly cheating, and MOSS does have a lot of code from online sources in its database.
- Posting in online forums asking people to solve homework questions (or parts thereof) for you. Clearly cheating - Duh!
- Unfortunately, we are aware that (1) there are solutions to many homework questions available on the WWW, and (2) even USC students tend to cheat quite frequently on homeworks. Please help us restore faith in the integrity of Trojans by not being those students.
We run MOSS on all homework submissions to catch inappropriate collaboration and plagiarism. If we catch you cheating, you will be reported to SJACS, no exceptions. Follow the above guidelines to make sure this doesn't happen to you.
Again, most importantly, you should never send your code or test cases to anyone other than course staff, for any reason. As soon as you send it, you have no control over it; it could get shared with a lot of students. When code or test cases are shared, both students are culpable! Remember: friends that pressure you for unreasonable help are not really friends. There are plenty of course staff and instructors who are here to help!
So suppose that you were kind of working next to a friend, helping each other out a bit, and along the way, you really saw too much of your friend's code. You didn't mean to cheat, but you kind of have your friend's code in your mind, and you're worried that the code you write yourself will resemble it too closely. And given that your instructors seem to be such hardasses ...
The "emergency" rule is to follow what Aaron likes to call the "Hearthstone Rule": erase all writen notes/photos/records from inappropriate collaboration. Then take a break (at least 30 minutes or an hour) during which you do something completely unrelated to the course. (Aaron recomends a few games of Hearthstone.) Afterwards, you return to your work, and you'll probably be fine.
The Hearthstone Rule is a failsafe to help you recover when you accidentally engage in inappropriate collaboration. Flouting the spirit of the Hearthstone Rule while following its letter does not excuse cases of cheating which arise. For example, it is clearly not ok to study and memorize your friend's code, play 30 minutes of Hearthstone, and then write out your friend's code from memory and submit it.
Now you know, and knowing is half the battle!