ICS 45C Fall 2016
Project Guide

The projects


This quarter, much of your focus will be on the programming projects found here. Being a course in C++ programming, all of these projects will be written entirely in C++; they are designed to expose you to a variety of concepts and techniques that are important in C++, and to prepare you for later coursework in ICS, such as ICS 46.

I do not assume that any of you will have previous C++ experience, though I do expect that all of you have at least a year or so of introductory programming experience in some language other than C++. For a lot of you, that will have been our first-year sequence in Python; others will have taken introductory courses in other places in any of a variety of programming languages. In general, if you have some experience programming in something — equivalent in depth to what you might have learned in our first-year ICS courses — you'll be fine, provided that you're willing to put in the time and effort to learn something new, especially something that might look and feel quite different from what you're accustomed to. Your most important focus when learning a new programming language is forming an understanding of the idioms the new language provides, as opposed to attempting a line-for-line translation from the language you prefer to the language you're learning; different programming languages encourage you to think differently about programming problems, and you might find C++ to be a big departure from what you've seen before, but big departures are how you grow your knowledge and ability.

Note that C++ programming requires a level of care and attention to detail that exceeds what you may have experienced in languages you've used previously, requiring a dual focus on both higher-level abstractions and lower-level implementation details that many languages hide and/or handle automatically. Focusing on the small details of the code you write is more important than it is in many other languages. Debugging can be more of an adventure, given that program crashes will not necessarily be accompanied with the clarity of diagnostics to which you've become accustomed. For these reasons, it's important to start your work early, encounter problems early, and get questions asked and answered early. Many of the most perplexing debugging problems I've ever faced in my professional career were in C++ programs, and having enough time to get these kinds of issues resolved may well be the difference between finishing your work or not.

While prior C++ (or C) experience is neither required nor assumed, it doesn't hurt; however, if you have prior experience, especially in C, you may find that some of the practices you've learned in the past are not acceptable in this course. We're focused not just on writing programs that generate the correct output, but at least as importantly on techniques that modularize programs, manage and hide complexity, and generally make the best use of what C++ has to offer, above and beyond what is provided by its C heritage. (It's important to realize that, while C and C++ share a common lineage, they have diverged in many ways over the 35+ years of C++'s history; be aware that our focus here is squarely on C++, not C.) We'll start with some of the baseline concepts first — and ignore a lot of the higher-level abstractions — but will quickly realize that writing clear C++ programs requires avoiding the manual, error-prone techniques as often as possible, so we'll gradually learn techniques to automate them or render them unnecessary.

Evaluation of your work

Evaluation criteria

Each of your projects will be graded on a 30-point scale, with the points split (albeit unevenly) into two categories: correctness and robustness (i.e., does the program work?) and quality and design (i.e., how well is the program written?). They are described in more detail below.

Criteria Value Description
Correctness and robustness 20 points
  • Summary: Does the program do what it's supposed to do for any input that meets the project specifications?
  • When the program is given valid input, does it generate the output specified?
  • Is the output spacing and case correct, if these are specified?
  • When the program is given unusual or erroneous input, and the project write-up doesn't specifically forbid us from testing it, is it handled gracefully?
  • Are all resources allocated by the program (e.g., memory, open files) released before the program ends?
Quality and design 10 points
  • Summary: Strive to write a clear, well-organized, readable, modifiable program.
  • Your program should be divided into logical parts, each encapsulating a single task or idea.
  • Large functions or classes should be broken up into smaller ones that do simpler jobs.
  • Identifier names should be chosen to reflect their objective; the names should be meaningful to the reader.
  • Comments should be included where necessary to introduce clarity for the reader (though it should be noted that good modularity and well-named identifiers make the commenting burden significantly lighter).
  • Any other rules and/or limitations specified in the project write-up should have been followed.
TOTAL 30 points

Code that does not compile

If you submit a program that does not compile, we will not be able to execute it and, thus, will not be able to evaluate its correctness. It is your responsibility to turn in code that compiles, and it's important that it compiles in the development environment specified for this course — more about that below. Though we will make an honest effort to assess its overall correctness and quality, we can, at our discretion, assign a score as low as zero to a program that does not compile, and you can assume that your score on such a program will not necessarily apporach the percentage of completeness and correctness you actually achieved, as it is impossible for us to measure that without being able to run and test your program.

At the level of experience that is assumed of you, you should be able to ensure that code compiles, even in a partially-completed program. You should be able to work incrementally, saving copies when you reach a stable state, so that you can always have at least a partially-working solution that compiles and runs. You might also consider using a source control tool like Git, which helps you to formalize this kind of incremental work, though this is not required. If you've never used a source control tool before, it would be worth the effort spent to learn about one; given its flexibility and popularity in professional and open source circles, Git is a very good choice. If you prefer something else, feel free to use it. (Git is installed on the ICS 45C VM, but you can install other systems on to the VM pretty easily if you prefer something else.)

Re-evaluation of your work

As projects are graded, you will receive scores and feedback on each in an email from a grader (either a TA or a reader). If you believe that you've been graded unfairly, your first move is to contact the grader and discuss the issue with him or her directly, as they are more familiar with the details of the grading of your work than I would be — the first thing I usually do is to contact them, anyway. Most issues are resolved this way. Note that we do not reconsider the rubric used to grade your work afterward, but if it was applied unfairly or incorrectly, we can consider an adjustment.

If, after this, you still believe that you haven't been treated fairly, you are welcome to raise the issue with me and I can arbitrate, though I should point out that it is relatively rare that I overrule a grader's judgment. I've communicated a fair amount with the graders about grading ahead of time, so they're generally acting on my instructions, so I don't find very often that I think a grader has graded work unfairly.

Late work

Things happen and ten-week quarters can be unforgiving. It's not unreasonable to expect that you may find it difficult to finish one of the projects on time, even if you're on top of things most of the time. I get emails often from students, saying things like If I just had one more day to work on this, I'd get it done! On the other hand, being consistently behind is a recipe for struggle in this course; we'll be moving quickly, and it will be progressively harder to catch up the farther behind you get.

The best balance between these two realities is that everyone is allowed to have a tough time with a project once this quarter with no penalty — maybe you underestimated the difficulty of an assignment, maybe you have three midterms and a paper due the same day, maybe you have a sudden outside commitment that can't be avoided. However, we generally require to keep up with the due dates as assigned, and we do generally assign a penalty for work submitted late.

Submitting late work

Aside from the "one-time" late submission, described below, late work is accepted according to the following policy:

Full or partial hours are counted. So, for example, a project submitted at 3:15am the morning after an 11:59pm deadline would be subject to a 4% penalty, because it was submitted 3-1/4 hours late (i.e., three full hours plus a partial one). In that example, if your score on the project would have been 27/30 ordinarily, it will be reduced by 4% and become 25.92/30 instead.

This means, in general, that a project submission has at least some value for 99 hours beyond the stated deadline. At the 100th hour, the project has no value remaining.

The "one-time" late submission

To accommodate the occasional unforeseen issue, we do also allow a "one-time" late submission:

For the purposes of clarification, here are some additional details about how this policy works.

In general, this procedure is automatic and does not require negotiation or notification; we will apply this consistently to everyone as described above. The goal is that this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time, while freeing course staff to focus on helping students improve.

What to do if you're chronically late

Out-of-the-ordinary circumstances sometimes warrant exceptions to this policy; if you are faced with a problem that is preventing you from getting your work done on time, either on a single project or chronically, please contact me and we can talk about how best to approach the problem. It's important to contact me sooner rather than later; earlier in the quarter, there are a lot more things I can do to help than there are in the tenth week or after the final course grades are determined.

Development environment

Unlike programming languages such as Java or Python, which make it a point to be (more or less) independent of the hardware and the operating system that they run on, C++ is decidedly platform-dependent. This is especially true in the recent years, as two new versions of the C++ Standard, called C++11 and C++14, have been completed, but not all compiler implementers have implemented all of the new features of the language yet (and library support is even more hit-or-miss). And even amongst the features that all compilers share, there are differences — all the way down to details such as the maximum value you can store in a variable of type int! — that make it important for us to agree on a single development environment: a particular compiler running on a particular version of a particular operating system.

Because not every one of you will be running the same operating system on your own machine, and to avoid the problem of having each of you install and configure the necessary software yourselves, the officially-supported development environment for ICS 45C is provided in the form of a virtual machine, a complete environment that includes an operating system, compiler, debugger, text editors, and so on; we'll call this the ICS 45C VM. Rather than installing software, you'll download the ICS 45C VM and run it as an application on your computer, but log into it as though it was a separate computer. This is explained in more detail in Project #0, which describes how to download it and set it up for use.

What if I don't want to use the ICS 45C VM?

Everything we do this quarter will be standard C++14. Aside from incompatibilities between compilers — both those arising from new features that are implemented by some compilers and not others, as well as platform dependencies — I would expect you to be in good shape using something else a large percentage of the time, though you'll find that you hit bumps in the road sometimes, and it may not be obvious when you do. You may end up writing a program that works in your environment but doesn't work in the provided environment; this is a realistic possibility in C++, especially when we're working with newer language features that aren't implemented in every compiler.

Be aware that we will be grading your work using the ICS 45C VM, so, at minimum, you should always test your projects in the ICS 45C VM before submitting your work. Submitting work that compiles on your favorite compiler but not in the ICS 45C VM is viewed the same as any other work that does not compile at all; as when you work for (or with) someone else professionally, you don't always get to choose your favorite environment to work, and have to adapt to what is appropriate to the situation. Additionally, be aware that you're on your own to get software other than the ICS 45C VM set up and configured; we can't realistically support everyone's separate home installation, whereas the ICS 45C VM gives us a single system to support.

Also (and especially if you've never used Linux before or spent a lot of time on a command line), you should consider the practical usefulness of learning new skills that will no doubt prove to be valuable as you pursue professional and academic options further down the line. Trying out something new while having the safety net of a large course staff to help you is a lot better than struggling with it on your own. Even if only for that reason, I'd strongly encourage you to use the ICS 45C VM for all of your work, even if it seems like a difficult transition at first. Linux and command lines are an important part of real-world computing, and you would be wise to gain some experience with them.

Submitting your projects

When you complete each project, you must submit it to us electronically to a web-based system called Checkmate. Follow this link for a detailed description of how to submit your projects via Checkmate. Understand that we will only accept projects submitted using the procedure described there; we do not accept printed copies of your projects, nor do we accept them via email or other means under any circumstances.

You are responsible for submitting the version of your project that you want graded. We will grade the most recent submission made before the deadline. Accidentally submitting the wrong version will not be considered grounds for a regrade.

Academic honesty

The policy

As ICS 45C or CSE 45C students, you are expected to know and follow the academic honesty policies of both the Bren School of ICS and the University as a whole. Please take a few minutes to read the policies, which can be found at this link.

All of your project work is expected to be completed solely by you. Worker in larger groups and/or sharing of code between students that are not partners is not permitted. Note that "high-level discussion of course material for better understanding" is permitted and encouraged, but when it comes time to sit down and write code, that is expected to be done by you and you alone. All submissions are compared to one another using an automated plagiarism detection system. This system is extraordinarily good at finding similarities between submissions, even when there are superficial differences. (Note that we also compare your submissions to those submitted during previous quarters whenever one of these assignments was given during a previous quarter, so it is an exceedingly bad idea to turn in, or even refer to, code written by a friend of yours who took the course already.)

Since all of your work is expected to be completed solely by you, you will be held responsible even if you plagiarize only a small portion of someone else's work.

Academic honesty is a two-way street. Providing your code to other students for them to turn in as their own is not permitted any more than turning in someone else's code. Resist the temptation to give code to your friends "for reference." Based on my experience, I can say that your "friends" may very well betray you and turn it in, anyway, and then you'll have a lot to answer for.

Naturally, the Midterm and Final Exam are also expected to be individual efforts. Dishonest behavior during an exam will not be tolerated.

Violators of academic honesty policies are subject to the penalties described in the Bren School of ICS policy. Penalties can include an immediate course grade of F — without the option to drop the course to avoid the grade. You shoud also be aware that I am required to document and report all cases of academic honesty, and that a single documented case of academic dishonesty may preclude you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors. All of this is University and Bren School of ICS policy and is not subject to negotiation.

Knowing when you're being dishonest

I've been asked by students how they know when they're crossed the line between asking for help and being academically dishonest. To me, there is a fairly straightforward way to know the difference. Did you actually write the code in question? That's not a matter of whether you typed it in; that's a matter of whether it was you who wrote it (i.e., it is comprised of your own ideas about how to solve the problem, how to organize the solution, and so on).

The easiest way to determine whether you've crossed the line is whether your work was driven by someone else's existing solution. Here are some examples:

In my view, this really isn't that complicated. We require you to do your own work, because that's how the learning is done in this course. If you're unable to do the work in the course, you're not ready to take courses that follow on from this one; cheating this quarter in an attempt to move forward anyway is simply delaying the inevitable failure that lies ahead until you successfully build your skills.

The lesson

Okay, so the moral of the story is that it's wise to avoid cheating. I believe that it's relatively rare that students enter a course with the conscious intent to cheat their way through it; why come to UCI if you're not planning to get something out of the coursework? So why do people cheat every quarter in every course? The answers vary, but here's the easiest way I can boil down the numerous conversations I've had with students caught cheating in my courses over the years: I fell behind and couldn't figure out how to catch up. Things happen and ten-week quarters are unforgiving. You might get sick, you might have issues crop up in your family, you might have misunderstood one of the earlier topics in the course on which later topics dependend, you might have an off-campus job that's demanding too much of your time, you might be trying to decide whether you're on the path you want to be on... Any of those things (and many others) can make it hard to keep up. You fall a little behind, you fall a little further behind, and pretty soon the situation seems hopeless. You're under pressure, temptation gets the better of you, and suddenly it seems better to submit someone else's work than to submit nothing. It's not.

If you feel like you're beginning to slip off course or things are getting beyond your control, the best thing to do is to talk to us sooner rather than later. We're here to help; we understand. But the reality of taking large-sized courses at a large-sized institution is that we're not going to know you're in need unless you tell us. If things are happening in your life, tell us; you don't have to be specific if you're not comfortable with it. Before the fact, there's often a way to work things out. After the fact, it's usually too late.