ICS 65 Fall 2012, Project Guide

Introduction

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++.

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. 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 high-level design issues and low-level implementation details that many languages hide and/or handle automatically. Being cognizant of the underlying implementation 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 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, though 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.

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. 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.

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, save copies when you reach stable state, and so on. 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.

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 — 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. For this reason, I'm offering the following late work policy:

Each student is permitted to submit any one project up to 48 hours late, with no questions asked about why and no prior notification required.

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

You are not required to notify us in advance — in fact, in all honesty, we'd prefer that you didn't. (There are a lot of students in this course, so that would represent a lot of extra work for us.) We'll be looking for submissions up to 48 hours beyond the deadline of each project.
There is a ten-minute grace period after the due date, allowing you time to get your files submitted to Checkmate. If you submitted your files at 12:08am for an 11:59pm due date, you're fine. Best not to play with fire, though, if you're already done before 11:59pm; at 12:11am, you'll have used up your one-time extension. No exceptions!
The first project that you submit late will fall under this policy; any subsequent project you submit late will not be accepted. (In other words, you can't submit two projects late, then wait to see which one you get a better score on; we won't be grading the second one.)
If any one file is submitted beyond the ten-minute grace period, the entire project is considered late.

We'll be tracking this throughout the quarter and, of course, will not grant the extension to anyone more than once. But this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time.

Other than this, late work is not accepted in this course.

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 assignment or chronically, please contact me and we can talk about how best to approach the problem.

Development environment

Unlike programming languages like Java or Python, which make it a point to be independent of the platform (i.e., the hardware, the operating system, etc.) that they run on, C++ is decidedly platform-dependent. This is especially true in the last year or so, as a new version of the C++ Standard, called C++11, has been released, but compiler implementers are still working on getting all of the new features of the language implemented, so each compiler implements a slightly different subset of the language at the moment.

The officially-supported development environment for ICS 65 is Visual Studio 2012. Visual Studio is an integrated development environment, with a wealth of features (mostly relating to Windows- and web-based programming) that we will not be using in this course. However, it does offer three features that are of tremendous importance to us:

Its C++ compiler is compliant with large swaths of the new C++11 standard, along with virtually all of the previous ones. No C++ compiler is entirely standards-compliant, but Visual Studio 2012 certainly comes close enough for our use.
It provides an integrated debugger, allowing you to place breakpoints into your code and step through it line by line, inspecting the values stored in variables as you go along. Debugging C++ can be difficult at times, so the debugger is sometimes essential.
While Visual Studio 2012 is ordinarily an expensive software suite, it can be obtained free of charge by all ICS 65 students, through Microsoft's DreamSpark program (formerly known as MSDNAA), which is described (albeit with its older name) here. For those of you who do not ordinarily run Windows, Windows 7 can also be obtained this way, and you can run it in a virtual environment such as VMware if you prefer not to install it on your machine.

How do I use Visual Studio 2012 once I've installed it?

Visual Studio 2012 is a large, industrial-strength development tool. As with most tools like it, it is possible to learn the subset of its features required for you to get your work done, while ignoring the others.

To mitigate the complexity of Visual Studio 2012, I've written a brief Visual Studio 2012 tutorial, which will take you through some of the simple tasks that you'll need to do in this course.

What about versions of Visual Studio older than 2012?

If you've already installed a version of Visual Studio older than 2012, you're going to want to install 2012, which can safely co-exist on the same machine with older versions. Recent additions to C++11, some of which we'll see in this course, are implemented only in the 2012 C++ compiler.

What if I can't or won't run Windows on my own machine?

Everything we do this quarter will be standard C++. 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 (such as gcc) 99+% of the time, and you can feel free to proceed in that direction.

Be aware, however, that we will be grading your work using Visual Studio 2012, so it's going to be vital that you stop by the ICS labs and test your programs before submission. Submitting work that compiles on your favorite compiler but not on Visual Studio 2012 is viewed the same as any other work that does not compile; as when you work for someone else professionally, you don't always get to choose your favorite environment to work, and have to adapt to what is given.

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 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 65 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 lab 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 anymore 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.

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. They are also subject to an immediate course grade of F, and you will not be allowed to drop the course to avoid the grade. Also be aware 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.

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 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...

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.