To be ready for each lab assignment, be sure to read it thoroughly before you commence work, and to review any material the lab assumes you know.
For each lab, you will need the lab assignment. You will also need a way to back up your work. If additional items are needed for a particular lab, we will list them in that lab assignment.
You have more time to complete some assignments than others; the due dates appear below. Take the length of time allotted for an assignment as an indication of how long it will take you to do the work; don’t waste the first week of a two-week assignment! As you work on your assignments, we strongy encourage you to seek assistance and advice from your programming partner and other students, the instructor, and other sources, consistent with following course honesty rules (discussed in the Course Reference).
You turn in your assignments via Checkmate, a Web application. To use Checkmate, simply go to checkmate.ics.uci.edu, log in using your UCInetID, and follow the instructions there. If you get a message about security certificates, just click "Continue." (You must have a UCInetID to use Checkmate. If you have not yet activated your UCInetID, do so right away; instructions for doing so are on the UCInetID Activation page. While Checkmate has proved to be reliable, if you think it is not working correctly, read the instructions carefully and try your action again. If you are then still having problems, send email to the instructor describing the problem as precisely as possible. We can only fix problems we know about!
We require that you keep your own backup, a computer copy of each assignment, just in case something happens to the copy you turn in. For example, if the Checkmate database gets hopelessly corrupted (which has yet to happen) we may need you to provide us with another copy of your work. If you do not have work we can grade, you will receive no grade for it.
You may work in any instructional ICS lab (ICS 183, 189 192, 364) any time it is open and not reserved for a particular class or function. See the Lecture and Lab section of the Course Reference for more details.
We use Java as the language of practice in this course, as implemented in Sun’s Java Standard Edition SDK 7.0 (also called version 1.7). We also provide, and take as the course standard, the Eclipse Classic programming environment. For labs where we provide existing code, it will be as partially complete source files or as Java 7 class files that are part of an Eclipse project. Note these provided files are not compatible with versions of Java earlier than Java 7.
You may complete your lab work anywhere, using any Java environment to which you have legitimate access; in particular, you can work at home and you don’t have to use Sun’s version of Java. However, to be fair, and to be sure we can check your running program, to obtain full credit for an assignment your work must compile and run correctly under Sun’s Java Standard Edition SDK version 7 in the Eclipse environment on the ICS Lab network. In particular, it is irrelevant whether your program runs perfectly on some other system: if it does not run on the ICS Lab network in Eclipse, using Java 7, you will not receive full (and may not receive any) credit for it.
Every lab assignment in this manual describes the assignment itself and what needs to be turned in. Here are the labs, the percentage they count towards your total lab grade, and their due dates:
| Smiley Faces | 20% | October 18, 2012 |
| Animated Smileys | 20% | October 28, 2012 |
| Animated Smileys, Graphics and Applet | 15% | November 15, 2012 |
| Smileys at the Races | 20% | November 27, 2012 |
| A Donation to the Music Archive | 25% | December 10, 2012 |
All labs are due by 11 pm sharp on the dates given. If a lab is turned in later than due, it incurs a late penalty, as discussed below.
Some of the assignments have optional work included. You may earn up to one additional assignment point by doing optional work, depending upon how much of the extra work you do and how well you do it, or for doing an amazing job on a lab (see below). This point is added to your total, but not to the total possible number of points; thus, not undertaking this work will not hurt the lab portion of your course grade. (Lab assignment points do not “spill over” into exam points; even if optional points put you over 100% of the lab points, only 100% of the lab points will be counted when computing your course grade.) You cannot get points for optional work unless all the required work is complete and correct.
We will grade your programs using the following five-point scale. Note that if you get four points, we consider that full credit for the lab—if you get four points on every assignment, you will have 100% of the possible lab points. Note that your grade depends on issues of programming design and style as well as those of correctness (Does the program function as it should?) and completeness (Does the program contain exactly the features required?):
0 points You did not turn in any work.
1 point Work that it is meager and poorly done. It would not be considered at all acceptable in academic or professional circles.
2 points Work of reasonable quality and completeness—a program that runs and implements at least the main requirements of the assignmentand shows at least a basic understanding of the material. Presentation may be lacking (e.g., written work shows poor composition, a spreadsheet is hard to read, a database is poorly organized, a program& is hard to follow or has a design that is cumbersome).
3 points Work of high quality that is complete and well presented—with perhaps a few minor errors and/or design or style problems. The grade for good, solid—but not extraordinary—work.
4 points Work of very high quality that demonstrates a full and complete understanding of the material the lab covers with a very polished presentation; any programming component of the assignment is complete (contains exactly the features specified) and correct (functions as it should, with no errors). Normally the highest grade awarded.
5 points Work of the highest professional or academic quality; it would earn highest praise from a professional or professor. Expect this grade to be very rarely awarded.
If it is difficult to determine whether your work is best represented by a score of x or x + 1 points (x ranging from 0 to 4), we may award a grade of x + 0.5 (that is, half points may be awarded). Expect this to be an unusual event.
Your programs will be graded mostly on their correctness and completeness, but will also depend on other qualities, such as efficiency, ease of use, reliability, modifiability, clarity, how quickly and easily your code can be understood, the reasonableness of your design and how well the programs follow the class style standards. A professional-quality program must score highly in all these categories—and part of what this class is all about is to help you learn how to write professional programs. In particular, you can lose points for poor design or bad programming style, even if your program correctly and completely implements the functional requreiments.
If an assignment has specific grading criteria that add to or extend the criteria given here, the assignment will describe them.
If you want to review your graded assignment, you can do so during office hours.
For a lab to be on time, your assignment must be submitted to Checkmate by the due date and time. Any assignment submitted after that time will incur a penalty of one point for each day or part of a day it is late. For example, if you earn three points and the assignment is two days late, your score will be one point (out of four).
We grade the latest version of an assignment submitted. For instance, if you turn in an assignment on May 5 and again on May 6, we will grade the assignment submitted on May 6. In particular, you cannot submit an assignment in parts. For instance, suppose you submit part of an assignment on May 2 and the rest on May 3. We will only grade the May 3 submission and treat it as your entire assignment.
We will not penalize you for a late assignment if it is late because of significant circumstances beyond your control, such as an incapacitating illness or injury or a major emergency. Conflicts with due dates for your other classes or your job are not sufficient cause to waive the penalty. Should you be unable to turn in an assignment when due, it is best to notify the instructor ahead of time and make arrangements for an alternative due date. If you cannot provide advance notice, turn in the assignment as soon after the due date as possible, and, if you think the penalty should be waived, email the instructor and ask for a penalty waiver; include with it an explanation of the unavoidable circumstance that prevented you from turning in the assignment on time.
We take “cheating”—academic dishonesty—very seriously. Your work in this class, including your lab assignments, is subject to UCI’s and ICS’ academic honesty policies, as well as the policies for this course. See the Course Reference for links to the ICS and UCI policies, and for the general policies for this course.
There are also some course academic honesty policies specific to lab assignments:
Some of you have written code, for some other class or an employer, similar to what you would write to complete our lab exercises. It’s quite all right to adapt your own previous class work for use in this class, if you wish. You also may reuse work you did for your employer, provided you have that employer’s permission and our permission to do so. It is not all right to adapt someone else’s work without our explicit permission and, often, theirs—doing so would be a violation of academic honesty policies and potentially a violation of copyright laws.
You can adapt any code course staff gives to you, provided you note in your program from whom you received the information. (Not giving others credit for work they did makes it appear as if that work was your own, and that, too, is a violation of academic honesty policies.) You may not use code others give you, such as code you received in some other class or some tutorial session, unless you have our explicit permission to do so.
You may adapt code from a text or other source only if we have given you explicit permission to do so, such as by a statement to that effect in a lab assignment, an announcement in lecture or lab, or an agreement you reach with the instructor. In any event, you must document that your work is based upon another’s, what work it is, and who gave you permission to use it; anything less is a major violation of academic integrity.
If the assignment is one that you are completing on your own, your assignment cannot be the result of joint work with another person. In particular, a person cannot work on an assignment with another person and then turn all or a part of it in as if it was her or his individual work. Turning in the work of another student who completed the assignment for you, or from whom you took work, and then presenting it as if it were your own work, is a particularly serious infraction of academic honesty policies.
If the assignment is to be done with pair programming, your assignment is to be joint work with your programming partner and only your programming partner. Turing in work of any other person or source is subject to the policies described above.
We compare your work, both by hand and electronically, with assignments submitted by students in this and other classes and sometimes to other sources, such as code from a book or the Internet. If we find similarities that appear to indicate that your assignment contains work that is not your own, except as allowed above, we will investigate to see if academic honesty polices were violated. If they were, you could receive a zero for the assignment, a lower couse grade than you otherwise would have received—including an F—and, in egregious or repeated cases of academic dishonesty, expulsion from the ICS major or even from UCI.
Using a good coding style is important, for many reasons. Professional programmers need not only to be able to read and understand their own code, months or even years after originally writing it, but also to read and understand code written by others, often in the absence of the original programmer. There is nothing more frustrating to a programmer than inheriting responsibility for someone else's code, only to find that the code is designed poorly, written cryptically, and documented shabbily (or not at all). In professional circles, it is critical that programmers write code in a clear style with adequate documentation; in this course, a consistent style makes assignments easier to understand, and thus for us to grade accurately.
The Java code that you write for this course should follow the style and documentation conventions discussed below. For any areas of style not addressed, use the style of code given to you for the particular assignment. If there is no provided code for the assignment, or that code does not address the style issue, follow the style used in the course textbook and its style guide (found in Appendix L). And if that does not address the issue, ask the instructor what style to employ.
Do not change the names we give to, or functioning of, code we provide to you. In particular, leave the names of classes, interfaces, methods and any other public items alone. Modifying the names or actions of provided code could easily break the system, as other components of the system on which you are working rely upon those names and actions.
About comments:
It is crucial that you include comments at the top of each .java file that you write or modify that include your name, your student ID number and your UCInetID. (There is no need to include comments in files we give you that you do not change.)
Every class, method and field should have a comment which briefly explains its purpose. For each method, include a high-level description of the algorithm it uses, if that algorithm isn’t obvious from reading the code. Also document the purpose of the method’s parameters and any assumptions about them. Describe what the method returns (if it is not void).
Within the body of your methods, comment code whose purpose is not obvious. It is not necessary to include a comment on every line. It is appropriate, instead, to have one comment which explains the purpose of a group of several related lines of code.
All constants, except obvious uses of 0 or 1, should be defined and named meaningfully. For example, if you were writing an array with a hard-coded maximum size of 256 elements, define a static final field such as MAXIMUM_ELEMENTS, and use that field in your code, rather than the literal integer 256.
Naming conventions for classes, members, and constants:
Class names should be capitalized. Class names with multiple words should have each subsequent word capitalized, with no underscore separating the words (e.g. Tunes, IrishFolkTunes).
Names of class members (methods and fields) should begin with a lowercase letter. Subsequent words should be capitalized, with no underscore separating the words (e.g. playSong(), songTitle).
Named constants should be named using all capital letters, with underscores separating the words (e.g. EULER, MAXIMUM_ELEMENTS).
Variable, parameter, method, and class names—in fact, all program names— should be meaningful, except that counters or other loop control variables may have simple names such as i or j, as tradition imparts meaning to these names.
Each method should do one task, well; in particular, main() should just get the ball rolling, with the bulk of work done indirectly via a method call or two. If a method is longer than about 10 to 20 lines, think carefully about whether it is undertaking too many chores or directly executing details that should instead be done by other, called-upon methods; if so, rewrite the method so that it calls other methods to handle the additioal chores or details.
Every field and method within a class should be declared using an access control modifier (i.e., public, private, or protected). Protected access should be used only when truly necessary.
Whitespace should appear between each method argument and around each binary operator. For example, createFile("alex.out", WRITE) instead of createFile("alex.out",WRITE); a + b instead of a+b.
One single line of code should typically not be longer than 70 to 80 characters. Don’t be afraid to break up long lines into multiple lines. For example, if you have a method call with a large number of parameters, put some on one line, some on the next, etc., such that each line is no longer than 80 characters.
Matching opening and closing curly braces should be aligned in the same column. This means that the opening curly brace which follows an if statement should appear directly below the letter i in if and not on the same line as the conditional expression.
All statements within curly braces should be indented about four spaces (or one tab) relative to the brace. A statement should not appear on the same line as the opening curly brace.
There are two style rules we enforce with particular rigor in this class because violating them indicates either a very poor program design or often causes major, difficult-to-catch errors:
You may not use a break except to break out of a case of a switch statement.
You may not combine the ++ and -- shortcut operators with any other expression. For example A[++i] = i; is not allowed (it should be ++i; A[i] = i;).
Remember that a significant violation of style standards could result in a lower score on your lab.