CS 70

Check Your Submission

After all the work you’ve done, it’s important to make sure that your submission is in good shape and that you won’t lose points for silly things.

Testing

Remember: the autograder will alert you about big problems, like if your submission won't compile and/or run.

It won't tell you whether your implementation is correct or whether your tests are thorough. That's your job!

You have a chance before your submission to take a critical eye to your tests and improve them both to improve your chances of a good score for testing and to see if you can catch any bugs in your implementation. For each operation brainstorm as many publicly observable consequences of that operation that you can. Make a test case for each one!

Formatting Your Code

Remember that we now allow you to use the clang-format command:

clang-format -i *.cpp *.hpp

It will try to change your .cpp and .hpp files to better match our Google-based coding-style convention (with settings taken from the provided .clang-format file).

clang-format won’t fix all cpplint errors, but it does handle lots of common cases such as missing or extra curly braces or too much/not enough whitespace.

Note: Don’t use clang-format as an excuse to write ugly code, and then hope that it will magically make your code readable!

Nobody writes perfect code even with experience with a particular style. clang-format is just a tool to help you catch some of the small oversights that inevitably happen but aren't caught by the compiler.

To Complete This Part of the Assignment

You'll know you're done with this part of the assignment when you've done all of the following:

Record Your Submission Code

When submit-this succeeds, it prints a submission code that looks like

Your submission code: 8A1F-BB41-P

Copy yours in here, exactly as shown—dashes and all. Either partner can enter it; because this is a group answer, it counts for both of you, and only one of you needs to run submit-this since your repository belongs to both of you. It is your receipt that you submitted, and it is how we match what you entered to the snapshot that actually arrived on GitHub.

Your code, as we graded it

77 points

Question 4.1

Autograder

When we grade your code we run the autograder on the commit your submitted branch pointed at after the deadline. Once grades are released, its score and its test-by-test report appear under this question.

Filled in by course staff.
20 points

Question 4.2

Code Review

When we grade your code, we record here exactly what we graded: your repository, the commit your submitted branch pointed at, and the submission code that goes with that commit. Once grades are released, our review of your code's naming, elegance, comments, layout, and idioms appears under it. We follow the Grading Guidelines and the Grading Rubric.

Filled in by course staff.
3 points

Question 4.3

Planning

You planned the three phases that ask for it before coding them and added the evidence to your repository's Planning folder (Phase_5.jpg, Phase_6.jpg and Phase_7.jpg). We check for completeness, not correctness, from the same commit as your Code Review record above.

Filled in by course staff.
Up to 3 bonus points

Question 4.4

More Fun with Search Trees (Optional Bonus)

If you took on any of More Fun with Search Trees, we look at what you did, from the same commit as your Code Review record above, and at how you described it in your Fun.md file. It's optional, and worth up to 3 bonus points: points over the homework's total, so skipping it costs nothing. Once grades are released, how it went appears under this question.

Filled in by course staff.

(When logged in, completion status appears here.)