Introduction to Computer Science II
ICS-22: Lecture A/Labs 1 and 2
Fall 2007

Introduction This page contains material that will be important and useful throughout the entire quarter. I consider it a contract with my students. Please read it once now, and keep it handy for future reference. You can search this page in your browser for specific information by typing Ctrl F or selecting Edit | Find on this page (Windows IE) or Edit | Find in This Page... (Firefox), then entering the text that you want to locate. Many questions that you might have about this course during the quarter are already answered inside this document (so become familiar with its contents). It also contains lots of good advice on getting the most out of this course.

Catalog Description "Abstract behavior of classic data structures (stacks, queues, sorted and unsorted maps), alternative implementations, analysis of time and space efficiency. Recursion. Object-oriented and functional programming. Prerequisite: ICS 21/CSE21 or ICS H21 with a grade of C or better. Same as CSE22. Only one course from ICS 22/CSE22, ICS H22, or Informatics 42 may be taken for credit.

Note: I will spend about 1-2 weeks introducing/reviewing the fundamentals of Java: data types, literals, variables, operators, expressions, statements, exceptions/handling, classes, objects, arrays, and interfaces. I do so to ensure that students who have learned Java know everything that I think is fundamentally important (using the vocabulary that I will use in this course), and that students who have learned programming in another language make the transition to Java.

During this time there will be a lot reading and working problems, and two simple programming assignments. I think the following quote is relevant for this part of the course.

The voyage of discovery is not in seeking new landscapes but in having new eyes.

- M. Proust

Don't "blow-off" the first few weekes, een if they seem like pure review. Use your time to firm-up and extend your knowledge of Java fundamentals.

Course Philosophy My goal in ICS-22 is for students to acquire fluency in thinking about, discussing, and writing programs in Java using appropriate abstractions. We will spend the first few weeks of the quarter reviewing fundamental Java language features (types, literals, variables, operators, expressions, statements, exceptions/handling, classes, objects, arrays, interfaces, Javadoc, etc.) to ensure that everyone has a rock-solid understanding of these features, which we will build on extensively later in the quarter. In the second part of the course, we will explore Java's mechanism for inheritance (advanced use of classes) and see it applied during our study of Java's standard collection classes and iterators; this will include using theoretical and applied complexity analysis to study collections. We will spend the final part of the course studying lists (and introduce trees), which are self-referencial (recursive) data structures (most easily processed by recursive methods); at the very end of the course, we will contrast the Object-Oriented/Function Programming styles (Java can support programming in either style).

This course emphasizes Object Oriented Programming (OOP). The foundational unit of OOP is the class: a syntactic structure that describes and encapsulates both the behavior (methods implemented by control structures) and state (fields implementing data structures) of objects. Classes provide an excellent motivation and context for exploring most interesting aspects of programming. We can view software as a collection of interacting objects (which are constructed from classes; often with many objects constructed from the same class).

The main programming methodology that we will learn and employ is iterative-enhancement, which decomposes a large project into a series of mini-projects (each is called a phase). Starting from a kernel, and writing a program for each of these phases in sequence, results in a solution to the original project. Each phase requires repeatedly specifying, designing, coding, documenting, testing, debugging, and evaluating a testable program that is a small extension of the capabilities of the program produced in the previous phase. Sometimes we will use JUnit to devise tests for our code, and then automatically test it (and retest it when we make changes). We will also study and actively use other Java tools for browsing, debugging, and documenting large programs.

Expect to cover most relevant Java language features thoroughly, but also to spend much time discussing the less concrete -but ultimately more general and important- aspects of programming. Programming style is a particularly important topic: to understand programming, we really need to develop appropriate aesthetics that allow us to separate "elegant" programs from "hacks". As in any writing activity, we must also learn to be self-critical of our own creations, so that we can continually improve them; this skill is difficult to acquire, and its importance extends well beyond the domain of programming.

Finally, to become an expert in any discipline, we must master its terminology. Fluency with technical terms allows us to communicate -and even to think- more accurately and concisely. Therefore, the materials in this course will define, illustrate, and repeatedly use many important technical terms concerning programming. Take the time required to master them. An old Chinese proverb says, "The first step towards wisdom is calling things by their right names."

Textbooks The primary materials for this course will come from web pages that I have written (and am continually updating). These web pages include readings, problem sets, and programming assignments (and a bunch of infrastructure material, like this syllabus). Typically, these web pages will be shorter than chapters in a textbook, but they are more densely packed with information; thus, you will still spend about the same amount of time studying my web pages as you would reading a textbook.

The UCI Bookstore will sell two textbooks that traditionally are used throughout the ICS 21/22/23 course sequence. If you took ICS 21 here, you will probably have the first book already, which contains much useful material about the fundamentals of Java (and covers quite a few advanced topics as well). If you don't have any textbook that discusses the Java programming language, I recommend buying this one, and reading it to fill in any gaps in your knowledge of Java.

If you plan to take ICS 23, you will be required to buy the second book, which also contains material relevant to this course (that you can use for supplemental reading). For ICS-22, these both books are recommended, not required.

  1. Horstmann, Java Concepts 5th Edition, Wiley, $91 new ($69 used).
  2. Goodrich, Data Structures and Algorithms in Java, 4th Edition, Wiley, $110 new ($83 used).
These prices are from the UCI bookstore. These books are also available used on the internet. See DirectTextbook, which crawls the web for cheap prices. Don't forget to account for shipping costs and delivery time if you don't buy from the UCI bookstore..

Computing Platforms and Programming Environments The standard computing platforms for this course are
  • Intel-based PCs running the Windows XP Operating System (OS).
  • Macintosh PCs running the OS X operating system
  • Either PC running Linux.

Programming courses at most schools are moving towards a model in which most students use their own computers (or those of their roommates or friends) to complete their programming assignments. All the software used in ICS-22 is available, for free, on the web. We are assuming that students have already installed a web browser, and have a high-speed connection to the World-Wide Web: e.g., via the campus network or a DSL line; having only a modem will make it more difficult, but not impossible, to work off campus.

The programming environment that we will use is Eclipse (version 3.2): it is an Integrated Development Environment (IDE), including a project manager, editor, compiler, debugger, class browser, help facility, etc. We will also use the Sun Java version 1.6.2 compiler and runtime system with this IDE. In addition, realVNC (Virtual Network Computing) allows students on their own computers to seek remote debugging help from a pool of course staff. This software, and others useful for the course, are available through the Online Resources link (see Course Software, near the top).

Talk to your instructor or TA immediately if you are experiencing any problems with your computing platform. Typically it takes only a few days before everyone has correctly downloaded and installed the necessary software, and learned how to use it properly. Using this software is integral to every programming assignment during the quarter, so it is best to be aggressive and master this software quickly.

ICS Labs
In addition to using their own machines, students can do their coursework on the machines in the ICS Labs, which are described on this link and in more detail below. The main upside of using the ICS labs is that it will be easy to get ICS-22 staff to help you there; the main downside is that you will not be using your own computer -unless you have a portable and bring it to the labs to get the best of both worlds. Read the following to learn about ICS Lab Account Activation. Whether or not you plan on doing your homework in a lab, you must activate your ICS account and know how to use it for in-class programming exams.

ICS courses often schedule lab hours (to complement lecture hours), during which students can learn how to use software tools and work on their programming assignments, all under the supervision of ICS-22 staff members. This quarter, both Lab 1 (MW 4pm-6pm) and Lab 2 (MW 6pm-8pm) meet in room ICS 189; other courses have labs in ICS 183 or 192. Each of these rooms contains 45 Dell Optiplex computers running Windows XP and all the necessary course software. These labs are typically open on weekdays during "normal" hours: 8:00am to 8:00pm, and they are closed on weekends; you may use these labs whenever there are no classes scheduled in them.

The lab in ICS 364 is a general purpose lab in which no courses are scheduled. It is open to students on weekdays and weekends during "extended" hours: MTuWThT 8:00am - 12:00am (midnight), F 8:00am - 10:00pm (midnight), and SaSu 10:00am - 10:00pm. You can examine the Lab Schedules for all these labs.

For information about where and when ICS-22 staff members are in labs, check the Help Schedule. Generally, ICS-22 staff will do all their consulting in ICS 189 (the same labs that we use as a schedule part of the course itself).

If you find it inconvenient to use these labs, and would rather work from your dorm room or off campus, ICS-22 staff will also provide more limited online help through Instant Messaging. If you have installed realVNC on your computer, we will be able to monitor and manipulate your computer directly from ours. We will discuss the details of this system for help, and how to use it, early in the quarter.

During in-class programming exams, you will have to write your programs on the PCS in ICS 189, so you should plan acquire some knowledge of these machines, even if you are using your own machine for all other coursework. Once you start Eclipse, PCs, Macs, and Linux systems operate similarly. Finally, although the machines in the ICS labs also provide some external storage space (on a Unix system), it is an excellent idea to obtain a USB memory stick to backup all the work you do, both on your own computer and in our labs.

Office Hours
I welcome students, individually or in small groups, to come by and talk with me during my Office Hours (see the Help Schedule), or whenever I happen to be in my office with the door open. If we need to talk, but you cannot come during my office hours, please call me so that we can arrange an alternative time to meet; or, maybe we even can resolve the entire issue over the telephone. Also, see the email section below, for an excellent way to ask short questions and arrange meetings.

I will be glad to talk with you about any of the ICS-21/22/23 courses, Computer Science, UCI, or whatever else you want to discuss. Although UCI is a large school, ICS is a smaller school within it, and ICS promotes opportunities for close faculty-student interaction, especially with instructors who are lecturers. Unfortunately, in my opinion, not enough students take advantage of this opportunity at UCI.

I especially encourage students who are having problems in the course to visit me immediately; I know that this is asking a lot, but the payoff for recognizing the situation and acting on it immediately is tremendous. The primary reason that students fail to thrive in programming courses is that they fall behind in their work -often because of what is initially a small misunderstanding; but, because of the cumulative nature of this course, even a small misunderstanding can quickly grow into a big one. Often, I can quickly diagnose and rectify such a problem one-on-one.

Getting help fast can critically affect your overall performance in this course: many times I've seen students start performing one grade level higher after coming in to get help during my office hours (a typical visit lasts for about 20 minutes).

Online Hours
I hold online hours every Monday, Tuesday, Wednesday, and Thursday (most programming assignments are due on Thursday evening) from 9:00pm-10:00pm. I will be logged onto AIM (AOL Instant Messenger) as richardepattis during these times.

If you are not already a member of AIM Sign Up for this service (it is free). Using this system, you will be able to Instant Message me, as well as use an audio (voice) connection if you have a headset with a microphone. You can IM me with questions; you can also cut/paste code into your message. Please be aware that I may be having multiple conversations, and therefore react more slowly than you might expect.

In addition, if you have installed realVNC (Virtual Network Computing) on your computer, it allows me (and other staff) to monitor and manipulate your computer directly from mine. For some problems, this is an excellent way to communicate.

If you have a small question (one requiring little back-and-forth discussion), and cannot directly contact me or any of staff, please ask it by sending me email ( It has been my experience that the act of writing a detailed description of a problem (detailed enough so that someone not physically present can understand it) often leads a student to his/her own solution of the problem. Frequently, before I even get a chance to read my email, I receive a second message saying, "Please ignore my earlier message, I solved the problem myself." I believe that the seeds of the solution are sown in the act of carefully composing the first email message. Here is quote on my website about this phenomenon.

Another effective [debugging] technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed "Never mind, I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.

- B. Kernighan & D. Pike (in "The Practice of Programming" pp. 123)

When I am not teaching nor attending meetings, I try to answer email every few hours during the day. I normally will not answer email sent after about 10:00pm until early the next morning (but I'll typically answer it by the next morning). If you have problems late at night "problems that the staff cannot help resolve" please send me email summarizing your problems, and then go to work on something else (or if it is really late, go to sleep). By planning to finish assignments early, you can protect yourself against a big problem that arises at night and cannot be fixed until the next day (you don't want to have to fix such a problem the night that an assignment is due).

For some problems -ones that are of general interest to the class- you should send email to the post a message to the course bboard (see below) so everyone can see the question and its answer..

Courseside EMail The Electronic Educational Environment (EEE) at UCI creates and maintains course-wide mailing lists. I have created a "merged" mailing list for all my ICS 22 students (which also includes those students signed up for CSE 22, both in the Sammueli School of Engineering and the Donald Bren School of Information and Computer Science). All members of our course (staff and students) can use this mailing list, whose email address is

If you have a question of general interest (of interest to many students in the course, not just you), then you should send email to this address. For example, if a lecture note, programming assignment, etc. contains unclear (or even contradictory) information, email a note about it to this mailing list, asking for a clarification. I, or someone from my staff will read and reply to whatever questions are asked. In fact, if you read a question on this mailing list, and know the answer -or generally have something to contribute to the topic, I encourage you to email a reply to help resolve the problem even sooner. Thus, the mailing list provides an out-of-class forum to discuss any course materials.

Again, this forum is appropriate for questions relevant to most students in the course; directly email me (see above) for questions of a more individualistic nature. Obviously students should neither solicit nor post answers to take-home quizzes, programming assignments, or anything else that would be interpreted as academic misconduct (which is discussed in greater detail below).

It is an excellent idea to read your email multiple times during the day, certainly whenever you are about to do coursework, to kepp up to date on any coursewide discussions.

Staff: TA, Reader, Tutor I will have various staff members to assist me in running this course. Our TA will primarily assist me during lectures and labs; he/she will also assist me by presenting optional help/review sessions, and help students to debug their programs during scheduled and optional lab hours. Our Reader will primarily grade programming assignments; if you have a question about how your programs are graded, please see the Reader first, and then come to see me if any questions persist. Our Tutors will primarily help students to debug their programs during scheduled and optional lab hours. See the Help Schedule for specific days and times that ICS-22 staff are on duty.

While consulting, the TA and Tutors will help you diagnose any computer/programming problems that you have and guide you toward a solution. They will help you learn how to program by answering your questions; but, do not expect them to write your programs for you. Sometimes when you come to the staff with a specific question, they will show you how to solve a more general problem. Be patient; the staff are just trying to teach you how to recognize and solve these problems by yourself.

The TA will also host a one hour optional help session in the early evening (one each on M, Tu, W, Th, Su). You can attend any of these help sessions, which are designed to review and clarify lecture material, help students solve the problems assigned in lecture, review recently returned quizzes and exams, or help students (conceptually) with their programming assignments -away from any computers.

These sessions are not lectures (and attending them is not a replacement for attending my lectures). You must come prepared to ask questions based on what you understand from lecture, and what is still confusing; the TA will answer your questions, filling in bits a pieces from the lecture as appropriate. Also, do not expect the TA to help you debug your programming assignments during these sessions (for that help, see the staff consulting hours -both online and in the ICS 189 lab- discussed above).

Classroom Information

Before Class I will place almost all the course materials on the World Wide Web (WWW). I expect students to read the required lecture materials before class, and work out solutions to the assigned problems (sometimes you can test/verify your solutions on the computer). Note that doing the reading and working on the assigned problems before class is a critical step in the learning process: students must be familiar with the material to get the maximum benefit from the class discussions and problem-solving sessions.

Solving the assigned problems is especially important, as it "proves" that a student has not only read the material, but "understood" it is as well. Here understood means "has used the information operationally to solve problems". If you have difficult with a problem, it indicates that you should probably review the related reading.

I will allow students to work together on these problems: to discuss them, to analyze how to approach solving them, and to collaborate on their actual solution. Such a discussion must go beyond copying another student's answer: it involves completely understanding the answer and the process whereby it was reached, which includes acquiring the ability to analyze and solve similar problems. In fact, students will be required to solve similar problems on (almost) weekly take-home quizzes, on which no collaboration is allowed. Don't cheat yourself in this aspect of the course.

Our TA will hold help sessions almost every evening to aid you with understanding each reading and how to solve its problems (see the Help Schedule web page for details).

During Class During class, I will discuss the lecture material, mostly by answering questions on the reading(s) and amplifying on those topics that need further discussion. Come to class with questions about any unclear parts of the reading or any problems that you could not solve (or are unsure of your answer). Class motto: "Those who are ashamed of asking are ashamed of learning. The only stupid question is the one left unasked."

I will randomly call on students to present their solutions to selected assigned problems, and discuss them as well (please be prepared). I may also ask students to solve, either individually or in groups, other problems relating to the material; we will then compare and discuss these solutions. Thus, I expect most "lectures" to be highly interactive, with students participating fully.

I expect students to attend class daily. During the 30 years that I have been teaching, I have observed a strong correlation between attending class and understanding the material (which ultimately affects grades). Having all the course materials on the World Wide Web (WWW) is a great resource, just as important is coming to class -and paying attention, once you are there, and participating by volunteering information when you know it and asking questions if you are confused.

I encourage you to participate by raising your hand; sometimes I may finish the point I'm making before calling on you, but please keep your hand up if you want to speak. If you have a question about the material, it typically means that I have explained something incorrectly, poorly, or incompletely, and that other students have (or will soon have, maybe right after they leave the classroom) the same question. So, it would be best for all of us to correct the problem immediately in class by someone bringing it to my attention. In summary, this class runs on the Dershowitz principle: "Question authority; but raise your hand first".

Class Decorum I expect students to attend class daily, arriving on time. The announcements made at the start of class are often very important; also, I reserve the right to give small pop-quizzes on the readings at the start of class. I expect students to neither carry on private conversations, nor use their computers to answer email, surf the web, day trade stocks, or perform any other activities unrelated to this course.

Unless you are responsible for someone's life, your cell phone should be turned off. Otherwise, you should set it to operate in some silent mode (as mine will be set); if it rings silently, please leave the class to answer it, with a minimum of disruption to the rest of the students. If your cell phone rings audibly in class, you will be charged $1; this money will go towards a class doughnut fund. Finally, if you know that you must leave early, please sit near a door, so that you can exit quietly.

Overall, please strive to be a considerate class member, both to me and to your fellow students.


Lecture Schedule/Notes, Programming Assignments, and Weekly Schedule.


Quizzes I will assign eight take-home Quizes to ensure that everyone is keeping pace learning the course material and is able to express themselves on technical matters both in English and Java. Each will have problems similar to those assigned daily in class (and similar to those on upcomming written exams; working these quizzes is a major way to "study" for these exams). These quizzes will be a take-home instrument: most will be distributed at the end of class on Thursday and collected at the start of class on the following Monday. During the weekend, you will have as much time as you need to work on the quizzes.

The quizzes are open-book: you will be able to use any class materials, or any other materials from the web, to answer its questions. But, you may not communicate with anyone about these quizzes nor their solutions. The quizzes are also open-computer: by that I mean that you may use a computer to check your work.

Programming Assignments I will assign five programming assignments to ensure that everyone is getting the necessary hands-on programming experience. While working on these programs, you will acquire a solid and fine-tuned understanding of the course material as well as gain important process of programming skills. Programs will typically be discussed and started in Lab on Wednesdays, and be and be due (submitted electronically) Thursday evening at 11:30pm (typically 1-2 weeks after they are assigned).

Students will often be required to work in groups of two on programming assignments. Such an approach is called Pair Programming. Each pair of students will submit one program with both their names on it (in the code/files). Apart from your pair, you can get general help from anyone (Instructor, TA, Tutors, friends, etc.) on programs. The best kind of help to get is oral: where you describe the problem, possibly showing your code, and then get an oral answer that you understand and translate into code. In such instances, you are learning.

You may neither copy nor transcribe (written or orally) any parts of another student's program.

When you submit your programs for grading, you are expected to understand all parts of them and have improved your process of programming skills while writing and debugging them. Students who complete their own programs in this way will be well prepared for the In-Class Programming Exams; students who get too much help (on purpose, or accidentally) will have a difficult time on these exams, which can severely impact their grade.

You will submit your solutions to programming assignments through a special web page that records the time they are submitted. To promote good time management skills, if you submit a program at least 24 hours before it is due, you will receive 2 points of extra credit. If you submit a program 48 hours early, you will receive 4 points. You can gain no more than 4 points of extra credit by early submission. For a 50 point assignment, this extra credit is equivalent to almost a full letter grade improvement. In general, it is a bad idea to submit programs more than 48 hours early (typically we will return graded programs on Tuesday, and you should wait to receive them before submitting your new program).

I know from long teaching experience that students who work ahead of the deadlines learn more, in a less stressed envrionment: students working right up to a deadline are more concerned with getting the right answer and less concerned with learning anything. On the other side of this coin, I will not accept any late programs. So, you must turn in your work on time: if you turn in a partially working program on time, it will receive partial credit; if you do not turn in anything on time, then I must assume you did no work on the program, and you will receive no credit. Therefore, always turn in whatever work you have finished by the official due time.

Written Exams I will assign one Midterm Written Exam and one Final Written Exam to ensure that everyone is successfully integrating all the material being taught. Its problems will be similar to those assigned on homework, and especially on weekly quizzes. These written exams are closed-book: you will not be able use any notes nor class materials while taking these exams.

The best way to study for these exams is to do all the homework and quizzes (and programs -sometimes material from programming assignments appear on these exams) and review these quizzes (and programs). We will also hold review sessions before these exams. Students are expected to be able to do these problems both quickly and accurately.

The final exam is comprehensive: it will cover material from the entire quarter (but concentrate a bit more on material presented after the midterm exam).

Programming Exams
I will assign two In-Class Programming Exams (taken during lab periods) to ensure that everyone can write (and debug) their own programs. The first exam will focus on using collection classes; the second on manipulating linked lists. Of course, you will have to know lots of general material about programming in Java to solve these problems effectively (as well as how to use the Eclipse IDE). Students will have an opportunity to take practice programming exams one lab before taking each actual programming exam.

The programming exams themselves will be closed-book; but, you will be able to access a copy of Javadoc for the standard Java library. I will grade these programs 90% on correctness: inapropriate use of Java -e.g., overly complicated or inefficient programs- will be penalized at most 10%.

Solutions and
Returned (Graded) Work
I will link, to the course web, my solutions to all quizzes, programming assignments and written/programming exams soon after they are due (which is another reason why I accept no late work). I expect that all students will carefully examine my solutions for immediate feedback. Note that the best time for you to study my solution is the day that I distribute it, having just spent a good amount of time working on your own solution. The sooner you examine my solutions, the more receptive you wil be to learning something. Finally, my solutions sometimes contain mistakes: if you are the first person to email me a correction, I will award you extra credit points (the same number that I would take off for the mistake).

I will return graded quizzes with two class meetings after they are turned in (since they are tyically turned in on Monday, I will typically return them on Wednesday). I will return graded programs on Tuesdays; do not submit new programming assignments until you have received feedback on your previous assignment. Finally, I will return written/programming exams within a week of when they are given.

If you believe that I have graded any of your work incorrectly, I encourage you to see me immediately about the discrepancy (in the case of programming assignments, see the Grader first). Such a discussion can have only positive outcomes: either I will agree with you that you deserve more credit (and, I do want you to receive all the credit that you are due), or you will come to understand the question, program, or solution better. This is certainly a win-win situation. In any case, carefully examine my solution before you come to see me.

Final Grades Your final grade is computed from your quizzes, programming assignments, written/programming exams as follows.

Instrument#Points EachPoints Total% of Grade
Programming Assignments55025025%
Midterm Written Exam115015015%
In-Class Programming Exams210020020%
Final Exam120020020%

Note that 55% of the grade is based on written work and 45% is based on programming; looked at another way, 55% of the grade is based on work supervised in class and 45% is based on unsupervised (take-home) work.

Based on your percentage, your final grade is computed as follows.

PercentageFinal Grade
80%-  89%B
70%-  79%C
60%-  69%D
  0%-  59%F

This is straight calculation, not based on a curve. I tend to grade programming assignments liberally, but quizzes, written/programming exams conservatively. I expect about a quarter of the student to earn As, about a quarter to earn Bs, about a quarter to earn Cs, and the final quarter to earn Ds and Fs. This course is NOT graded on a curve, so these are only expectations from past course performance, not mandated numbers. FYI: for the Spring 07 quarter, the actual breakdown was: 27% As, 24% Bs, 25% Cs, 13 Ds, and 11 % Fs.

After finishing 3 quizzes, 3 programming assignments, the midterm, and the first in-class programming exam, you have a reasonable indication of your final course grade (which, of course, will still heavily depend on the grades you earn afterward).

Academic Integrity

First, read the official Bren School of Information and Computer Sciences Cheating Policy which is just one of many of the many Undergraduate Policies with which you should become familiar.

The following information is my own restatement of this policy, as it applies in my course (originally written while I taught at CMU). You will also be asked to read and sign a handout to acknowledge that you understand the Academic Integerity Contract in force for this course.

Policy The decision as to whether a student has cheated depends on the intent of an assignment, the ground rules specified by the instructor, and the behavior of the student. The following two guidelines help an instructor decide if cheating has occurred on programming, which is the fuzziest area:
  • Plagiarism will be suspected if an assignment that calls for independent development and implementation of a program results in two or more solutions so similar that one solution can be converted to the other(s) by a series of simple transformations.
  • Plagiarism will be suspected if a student who completed an assignment cannot explain both the intricacies of the solution and the techniques used to generate that solution.
It is unreasonable to expect a complete definition of cheating that would cover all cases, because each situation is important enough to merit careful, individual scrutiny; however, it is helpful to have guidelines and precedents.

Here are some examples that are clearly cheating and clearly not cheating.

Examples of cheating:

  • Turning in someone else's work, in whole or in part, as your own (with or without his/her knowledge), without it including a statement of collaboration in the solution.
  • Allowing another student to turn in your work, in whole or in part, as his/her own, without it including a statement of collaboration in the solution.
  • Turning in a completely duplicated assignment. Even if all the comments are changed, all the variables names are changed, all the whitespace is changed, and the code appears in a different order: it is still the same program.
  • Several students/pairs writing one assignment and turning in multiple copies, all represented (implicitly or explicitly) as an individual student's/pair's work, without it including a statement of collaboration in the solution.
  • After receiving graded written work, returning written work, for regrading, which has been altered.
  • Finding a solution to the same problem on the web and submitting it without explicit attribution in the solution.
  • Stealing an examination or solution from the instructor.
Generally, you should NOT EXAMINE, by reading hardcopy or by copying a file, the program of any other student (nor should you let anyone examine or make a copy of your files). Doing so can easily lead to an intended or unintended academic violation.

If you ever feel that after talking to someone about a program, which is legal, your solution will be very similar to theirs, cite the consultation in the header comment in your program. Doing so protects you from University disciplinary action (although the instructor is free to grade the material as he/she sees fit).

Examples of NOT CHEATING:

  • Turning in work done alone or with the help of the course's staff.
  • Submitting one assignment for a group of students if group work is explicitly permitted (or required, as in pair-programming).
  • Getting or giving help about using the computers.
  • Getting or giving help about solving syntax errors.
  • High level discussions of course material to better understand them.
  • Discussing assignments to better understand them.
Again, the key here is not studying, verbatim, someone else's code, and then reproducing it as your own work. It is too easy to copy such code without really understanding it. Technically, for programming assignments, even understanding the resulting code is not enough (if someone else wrote it): you should also play an active role in synthesizing and debugging it. The course is as much about skills as about knowledge.
Automatic Detection of Cheating Recently, various cheating-detection software systems have become widely available. Some use search engines to compare selected portions of submitted papers to content on the web. In the context of programming, they compare each student's program to those submitted by his/her classmates (for this semeseter, and any previous semesters if the assignment has been repeated). This software does not compare programs exactly: it ignores format changes, variable name changes, and a variety of well-know transformations that change the look of code but not its underlying logic.

Many courses in ICS use this software to spot potential cheating cases. Once it identifies suspicious behavior, instructors carefully examine the flagged code to make a final determination as to whether students will be prosecuted for cheating. Often instructors can find additional evidence of cheating, once this software points them to the simlar code.

Penalties ICS will not condone cheating by students in its classes. When cheating is suspected, instructors will take reasonable action to establish whether or not it has actually occurred. If, in the instructor's opinion it has, the instructor will apply appropriate disciplinary policy. In my courses, for a typical case of cheating, the student will be awarded negative credit for the assignment (under the precept that not doing an assignment, and receiving no points, is better than cheating on it). For particular egregious forms of cheating (e.g., cheating on exams, stealing another student's work so he/she cannot submit it for credit), higher penalties can be extracted (from loss of a letter grade, through immediate failure of the course, up through suspension or expulsion from UCI).

Instructors must contact the student within 15 calendar days of discovering evidence of academic dishonesty and evaluating the relevant work. Notice of any action taken by an instructor will also be forwarded to the Associate Undergraduate Dean of ICS, the Associate Undergraduate Dean of the student's home school (if different), and the Office of the Dean of the Division of Undergraduate Education. These offices act as a repository for such information, in case the student commits multiple infractions.

Student Rights In the event that a faculty member accuses a student of cheating and imposes a penalty, the student has the right to appeal their case through the Associate Dean of Undergraduate Education in the faculty member's school or through the University Ombudsman. For more details, see The UCI Academic Senate Policies on Academic Honesty.
Final Words:
A Personal Statement
Cheating undermines the fabric of education. The atmosphere at UCI (contrary to whatever opinions, prejudices, or superstitions you hold) is one of fostering cooperation between faculty and students in the pursuit of learning, knowledge, and wisdom. This course, for example, is graded on an absolute scale, not a curve; so, helping other students doesn't affect your grade. And, if a student cheats for a higher grade, other students do not receive lower grades as a result.

Although it is embarrassing to fail an assignment, getting caught cheating is much worse. I know, though, that students rarely think about getting caught. But think about it: I often see students break down and cry when they get caught cheating and only then start to realize the consequences of their actions. Their stress level goes through the roof and it immediately affects both the academic and social parts of their lives. The process is distressing for me too, although I must confess that I have been hardened by the number of times that I have had to go through it (typically multiple times each semester). Pursuing these cases at the University level takes a lot of my time, and reduces the time that I can spend on more important matters relating to my course and my students. It is definitely a lose-lose situation.

The #1 excuse that I hear for cheating is, "I was pressed for time, so I cheated." By carefully managing your time, you can avoid this problem. If you start working early enough, and run into problems (and you should expect to run into problems), you will have time for the course staff to help you learn to solve them. Also, I understand that some students take this course only because it is a requirement for their major, and that they have little intrinsic interest in the subject area; this is not a valid excuse for cheating either.

I have seen too many instances recently where student A asks a friend, student B, for help; specifically, A asks to see B's quiz or code (on paper or in a computer file). Often, A copies B's code (with or without B's knowledge). I understand that B feels pressure to give A help. But, B is doing A no favor if A's cheating is discovered; B has made a bad situation (A would receive no credit) worse (A receives negative credit and is reported to the Dean of Student Affairs). And, according to UCI's rules, B can get into trouble for these actions too. I have seen friendships shattered because A copies B's code without telling B what was done, and then both get prosecuted under UCI's rules.

A similar situation arises with cheating on quiz questions. I have seen too many students cheat on one question on a quiz and receive a negative score for the whole quiz (and letter to the Dean of Student affairs), when leaving the question blank would result in a small point deduction and no university action.

In my final statement here, I ask you to pause and reflect on the consequences of choosing to cheat at UCI: this includes the impacts that it will have on you, your parents, your siblings, your friends, and your fellow classmates at UCI. Cheating is invariably the wrong decision.

Exceptions to Policies I have strict policies regarding attending classes, taking quizes, submitting programs, and taking in-class exams; but, there are exceptions. Exceptions to these policies include valid medical excuses (if documented by your Doctor or Health Care Provider), or any other officially excusable absence: emergencies, family problems, religious observances, job interviews or sports-related trips, etc. (if documented by the Office of the Dean in your College, a Coach, etc).

If you need such an exception, bring a copy of the required documentation to me as soon as possible: beforehand if you know about the problem in advance, on the next day that you are able to attend class (or during my office hours) if you do not have advance warning. I will need to keep the copy for my records. Again, if you have advance notice of a problem, please notify me by email beforehand to discuss any ramifications.