Coding without an IDE

There will come a time (paper exams, job interview, whiteboard talk) where you will be asked to write code without an IDE. Writing code without having the ability to run it is a somewhat different experience than writing code in Qt Creator. Specifically:

• You will not have a compiler that can point out syntax errors.
• You can’t run the code, tweak it, and revise it until it works.
• You cannot run test cases against your code.
• You can’t step through your code in a debugger.

This means that the process by which you’ll need to problem-solve is different. You’ll need to sketch out where you’re going a bit more than what you’re used to doing in Qt Creator, and you’ll need to be comfortable switching from a high-level idea to something more concrete. Additionally, you’ll need to be pay a bit more attention to details, since there isn’t going to be a compiler to catch your errors for you.

But there is upside in this format we won’t be evaluating your code using the standard of “does it compile, run, and work flawlessly?” If we did that, chances are most people would get zero points because a single misplaced brace or stray semicolon would derail everything. Instead, we’ll be asking questions like these:

• Do you demonstrate a solid command of the C++ syntax we’ve covered so far?
• Does the approach you’ve taken demonstrate a good understanding of how to choose and apply an appropriate problem-solving strategy?
• Is your code well-structured in a way that shows a facility with breaking larger problems down into smaller pieces?

In the IDE, even the smallest typo or syntax error stops the entire program in its tracks. On paper, we don't even deduct for these kind of errors if we are otherwise confident of what you intended. A conceptual problem using the wrong recursive strategy in a recursion problem or the wrong container type in a question on collections would be a more serious concern.

In this context, we won’t be grading for style at the same level as what we’d be looking for on the assignments – we understand that we’re essentially grading a first draft. However, you should still aim to make your code easy to read. For example:

• Please use descriptive variable and function names. Single-letter variable names (or worse, single-letter function names) make it significantly harder to understand your code.
• Please properly indent your code. This is especially important in the event that you forget curly braces somewhere and we need to make an educated guess as to what you intended to do.
• If possible, give comments demarcating the different parts of your code. This isn’t required, but if you have anything you think is really gnarly, it never hurts to add a comment explaining what you were trying to do!

There are a few details we don’t care about, so let’s save you some time:

• You don’t need to add #include statements at the top of your code. Assume they’re all there.
• You don’t need to write function prototypes.

Why not an IDE?

Students often ask why exams are not done like assignments: using a compiler, having code completion and searchable documentation, being able to run, test, and debug, etc. We have tried this in the past and it didn't work they way we'd hoped. What we learned was that the immediate feedback from the IDE more of an impediment than an advantage in these situations.

Imagine this scenario: you read the first problem and have a good idea how to solve it. It takes you 20 minutes to draft a solution. You trace its operation and feel good about it. Let's say your answer is most correct, has minor syntax issue and a small bug that causes a few inputs to be improperly handled. Overall it would earn 8/10.

But if you can compile it, you certainly will. You have to fiddle with resolving syntax issues (that were likely not even scored). Next you spend time testing it. Although testing confirms it works correctly for most inputs, you now see that it has a bug. So you hunker down and rework and retest until perfect. Having spent an additional 20 minutes fixing these issues earns you a perfect 10/10, but the extra effort for the final 2 points was a tiny payoff and you have less time for the remaining problems

The even more devastating outcome were students who just plain got stuck on a bug and never advanced past the first or second problem. No matter how much we advised students to draft a good answer and keep moving, if confronted with direct evidence that the answer was not fully correct it was near impossible to move on.

We know there are limitations to working without the benefit of a compiler and debugger, and we account for that in how we design and grade the exam. We are assessing your ability to think logically and use appropriate problem-solving techniques. We expect you to express yourself in reasonably correct C++, but we will be quite lenient with errors that are syntactic rather than conceptual.