Check Your Submission
After all of the work you've done, it's important to make sure that your submission is in good shape, and you can get all the credit available, including the credit given for doing various things “the right way”.
Testing
Remember: the autograder will alert you about big problems, such as if your submission won't compile and/or run.
The autograder 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 final 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 the Google-based coding-style convention (as controlled by the provided .clang-format file).
clang-format won’t fix all cpplint errors. If you need to #include another header, or need to add the explicit keyword in front of the declaration of a single-argument constructor, you’ll have to do that manually. 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.
(When logged in, completion status appears here.)