Check Your Work!
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”.
Like adding your partner! Somehow I keep forgetting!
Exactly!
Read over the hints below, and the checklist, and then submit your work.
Testing Feedback
The autograder output will tell you if your code compiles and runs with our testing programs.
It will not tell you whether your tests are thorough or if your code is correct! Just because there is no red text in the autograder output doesn't mean that your submission is perfect!
My test suite helped me find all the bugs in my code, so it's good, right?
-
That's great, but we'll test your tests on various buggy implementations. For full credit, your tests need to detect the common errors we've (deliberately) made.
So maybe take a breath before you call a submission your final submission.
Oh, no!
-
It's not that bad. Just think about whether there's anything else you should consider testing.
-
For each operation, think of all the things that should be both publicly observable and true. Write a test case (or cases) for each of those observable outcomes!
Code Formatting
-
Here's a tip that might make your life a bit easier!
-
Gasp!
Gasp!
Gasp!
I am intrigued by this unprecedented turn of events.
We’ve been asking you to format your code according to the Google style guidelines (with a four-space indent) as interpreted by the cpplint tool, because we believe it is valuable to practice writing code in a particular (known, readable) convention.
By now you should all have a pretty good idea how to lay our your code using that style, so it’s time to mention that there is a shortcut that you can use to fix many minor errors in a single step!
Specifically, commit all your changes (so you can undo the changes the tool makes if you don't like them), and then let the clang-format command reformat your code nicely according to our conventions by running:
clang-format -i *.cpp *.hpp
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.)