Coding without an IDE

Written by Keith Schwarz

This advice was written by Keith Schwarz for his CS106B students preparing for a traditional timed exam. We hope you find the advice here to be helpful when preparing, even though we have some slightly different constraints on our diagnostic this quarter. Keep in mind that we are providing you with a Qt Creator project, but that it isn't going to be set up to compile and test your code. It is more for your familiarity and convenience.

Coding without an IDE

Being asked to write code without having the ability to run it is a fundamentally 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 map 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 more detail-oriented than when you’re using Qt Creator, since there isn’t going to be a compiler to catch your errors for you.

The flip side of this is that 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?
  • Do the approaches you’ve taken to the demonstrate a good understanding of the problem-solving strategies we’ve talked about so far?
  • Is your code well-structured in a way that shows a facility with breaking larger problems down into smaller pieces?

So, for example, a single missed semicolon or something like that is probably not going to lead to any point deductions, but 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.

Preparing

There are a number of ways that you can prepare for this upcoming assessment/exam. Here is our recommendation of what you should do to get into the best shape that you can.

  1. Work through the section problems. The problems we give out in the section handouts each week are a great way to practice specific skills. Want to sharpen your recursion skills? Look at Section Handout 3 or Section Handout 4. Want to shore up your C++ fundamentals? Look at Section Handout 1 and Section Handout 2.

    When you’re working through those problems, don’t just hand-write things and call it a day. You’ll want to make sure that you actually got things working. So download the starter project, type up your solution, and try running it on some sample test cases. If things work, great! If not, try debugging your code and see if you can fix it. If you’re still stuck, no worries! That’s a great indicator that you should ping your SL or drop by the LaIR to get some help.

  2. Review IG feedback and make sure you understand it completely and unambiguously. We hold interactive grading sessions on the assignments for a good reason – it’s a chance for someone with more coding experience than you (your section leader) to offer their advice and insights about how you can do a better job in the future. If you haven’t yet done so, take some time to review the feedback you received. If there are suggestions of the form “try doing it this way next time,” take a few minutes and actually go do it the other way. If there are stylistic points that they’ve pointed out to you, great! Go patch up your code to meet those style guidelines.

    And hey, what should you do if you find something that you don’t understand? Ping your SL and ask for some clarification!

  3. Ask questions. As you're studying, take the initiative to ask us questions when you have them. If you're not sure about how or why a certain piece of code works, or why a certain piece of code doesn't work, or why a certain concept works a certain way, etc., go on Ed or stop by the LaIR and ask us a question. If you worked through any practice problems (esepcially from section hadnouts), ask your section leader to review your answers and offer polite but honest feedback on how you did and what you need to work on. You can also visit office hours if you’d like!

Good luck! Remember, this is a learning opportunity for you more than anything else!