CPSC 225 Intermediate Programming Spring 2008

CPSC 225 Policies

You are expected to be familiar with the course policies stated below. Ignorance of a policy is not an excuse for violating a policy or being surprised when it is applied to you, and will not exempt you from its penalties.

Email/Web Policy

You are expected to regularly check your HWS email and the course web page. Announcements, assignments, handouts, and other information relevant to the class as a whole will be posted on the course web page. Email will be used in the case of a particularly time-sensitive announcement (e.g. an announcement about an assignment which is due in the next class meeting) or for matters which are only relevant to a few people in the class.

Assignments and Evaluation

Readings: Readings will be drawn from the textbook, Internet resources, and other handouts. There is not a great deal of reading, and it is expected that you will do the assigned readings. Some material in the assigned readings may not get covered in class.

Labs: Lab exercises are intended to provide practice and reinforce specific concepts from class. Lab assignments will be posted on the syllabus page prior to each lab session; completed labs are due by the start of the following week's lab. You will generally not be able to read the lab assignment and complete all of the exercises during the lab period, thus it is important that you read the lab handout before lab so that you can maximize your efficiency during lab. Anything you don't complete during lab will have to be finished on your own as homework.

Programming Assignments: This course is intended to develop your skills as a programmer, and that means it is necessary to practice programming. Most programming assignments will be two-week projects, but a few will be shorter or longer.

Exams: There will be two midterm exams and a final exam. The dates and times of these exams are noted on the syllabus - be sure to consult this schedule before making travel arrangements! More details about each exam will be announced prior to the exam.

Attendance: You are expected to attend and be on time for all class and lab sessions, and to participate in class. Late arrivals may be marked as absent. More than three absences (for any reason) will lower your final grade by 0.5% per additional absence. No distinction is made between excused and unexcused absences when computing the final grade; however, the number of unexcused absences is taken into account when considering borderline final grades.

Participation: You are not expected to volunteer for everything, but you should be actively engaged in class - this means that you are paying attention and contribute meaningfully to the class on a regular basis. You should not hesitate to ask questions about the course material, either in class or outside of class via email or office hours - if you remain confused about something, it will make the next topic that much harder.

Final Grades: Final grades in this course will be computed as follows:

  • Labs: 20% (approx. 1.5-2% each)
  • Programming Assignments: 55% (individual assignments will be worth approx. 4-18% each)
  • Midterm Exams: 15% total (7.5% each)
  • Final Exam: 10%

Program Grading Criteria

Programming assignments will be graded on two major points: the functionality that has been implemented, and the quality of the program. The specific criteria and expectations are outlined below.

Functionality: Are all of the features required by the specifications implemented? A All of the functionality required by the specifications has been implemented.
B Most of the functionality required by the specifications has been implemented - only minor features are missing.
C Much of the functionality required by the specifications has been implemented, but a few significant features are missing.
D Many significant features are missing.
F More is left undone than has been done.

Program quality is scored according to several criteria. The relative weight of each point is outlined below.

Correctness: Are all of the features required by the specifications correctly implemented (no bugs)? Programs which do not compile will receive an automatic 10% deduction. 50% A Any bugs are few and minor (e.g. off-by-one errors); bugs do not indicate errors in understanding the logic of the program. Program compiles.
B Much of the program is bug-free. There are only a few instances of bugs in the logic.
C Minor bugs are common, or there are more than a few logic bugs.
D There are many bugs, a few of which may indicate significant errors in the program logic.
F Bugs are widespread, and there are many significant errors in the program logic.
Robustness: Are error conditions thoroughly checked? Are errors handled in an appropriate manner? 15% A Error-checking is thorough; any problems are few and minor (e.g. not checking an unusual situation). Errors are handled appropriately.
B Most error conditions are handled appropriately. A few cases are missed, but error-checking is thorough in most circumstances.
C Some cases are thoroughly error-checked, but many others are incomplete. Some error conditions are not handled appropriately.
D An attempt is made at error-checking, but there are many missing cases. Errors are often not handled appropriately.
F There is little or no error-checking. Errors are not handled appropriately.
Implementation Choices: Does the organization of the code into classes and methods reflect the principles of abstraction, information hiding, and encapsulation? Do the representations and data structures chosen for the program's data lead to simple and efficient implementations? Are problems solved in a reasonably efficient manner and without an excess of convoluted logic? 15% A The code is well-organized, appropriate data structures have been chosen for the task, and unnecessarily complex or inefficient logic is avoided.
B Some code may be unnecessarily complex, but the code is well-organized. Most data structures are appropriate for the task.
C Some of the code may be poorly organized, but there is evidence that the principles of abstraction, information hiding, and encapsulation have been employed in other cases. Some data structures are inappropriately chosen. There are multiple instances of unnecessarily complex code.
D A significant proportion of the code is poorly organized, and many choices of data structures are inappropriate. There are multiple instances of unnecessarily complex code.
F The code is poorly organized, and there is little or no evidence of the principles of abstraction, information hiding, and encapsulation. Poor choices have been made for most or all data structures, resulting in inefficient implementation or awkward representations. The logic is often overly complicated.
Documentation: Are all classes, methods, and instance variables and constants properly commented using the javadoc style? Are local variables and constants properly commented? Do the comments contain the necessary information? Are they well-written and clear? Is the README present, complete, and well-written? 10% A Comments are generally complete, well-written, and formatted properly. Any problems are few and minor e.g. formatting problems, omitting a piece of information. The README is present, complete, and well-written.
B Most comments are complete, well-written, and formatted properly; only a few are missing or incomplete. The README is mostly complete.
C A significant number of comments are missing or incomplete. The README is incomplete.
D Many comments are missing or incomplete. The README is incomplete.
F Little or no commenting. README missing or very incomplete.
Readability: Are the naming and whitespace conventions followed consistently? Are names descriptive? Is the code well-organized within each module? Is the code within each module easy to follow? 10% A Names are descriptive and of appropriate length. Naming and whitespace conventions are followed consistently, and the code is well-organized within each class with related elements grouped together (e.g. instance variables first, then constructors, then getters/setters, then other methods). Whitespace and comments enhance the readability of code within methods.
B There are only a few instances of poor naming, violations of conventions, or poor organization.
C Multiple areas of the program exhibit poor naming, violations of conventions, or poor organization.
D Many areas of the program exhibit poor naming, violations of conventions, or poor organization.
F Readability is largely ignored - many names are poorly chosen, there seems to be little regard for naming and whitespace conventions and for using these conventions to improve readability, and there is little or no effort to organize the code within classes or methods.

The functionality score (out of 100%) will be scaled by the quality score (also out of 100%). This is to encourage incremental development and testing and the integration of error-checking and handling, commenting, and readability into the development process instead of being things that are tacked on at the end - a correct, robust, well-designed and documented, readable program which doesn't meet quite all of the required functionality will score better than a program where all of the functionality has been implemented but there are significant bugs and poor commenting.

Late Policy

Late labs will not be accepted. It should be possible to complete much of the lab assignment during the lab period, and lab assignments are due one week after the lab session to allow time to finish anything not done during lab.

Late programming assignments will not be accepted more than two class periods after they are due. (e.g. an assignment due Friday will not be accepted after the following Wednesday) In addition, late work will be penalized 5% if turned in by midnight on the due date and 10% per day or part of day thereafter. (e.g. an assignment due Friday will be penalized 30% if it is turned in on Monday) Deductions are calculated as a percentage of the total points possible on the assignment, not the number of points you earned. This policy is intended to discourage habitually late handins and to prevent one late assignment from taking away time needed to work on the next, while still recognizing that sometimes there are circumstances where one just needs a bit more time.

No work will be accepted after the end of the timeslot in which the final exam is scheduled.

Note that computer labs may not be available at all hours or over college holidays, so be sure to take this into account if you are relying on those facilities. Furthermore, labs tend to get very busy right before deadlines, especially at the end of the semester. "I couldn't get my work done because I couldn't find a computer!" is not a valid excuse.

Missing Class / Make-Up Policy

Excused absences include absences due to sports competitions, official Colleges activities such as musical performances or debate competitions, academically-related events such as attending a conference, religious observances, serious illness, or personal or family emergencies. A reason must be provided in order for such an absence to be counted as an excused absence.

Missing class for other reasons - such as being too busy, oversleeping, or leaving early for a vacation - is considered to be an unexcused absence.

Students are responsible for acquiring any notes, handouts, assignments, and other material missed as the result of an absence, whether excused or unexcused. This should be done promptly to avoid falling behind.

Making up work (missed exam or assignment deadline) will only be allowed in the case of an excused absence, and only when it was not possible to have made arrangements in advance. Making up an exam requires documentation from an appropriate person (dean, doctor, etc) to validate the reason for the absence. Arrangements for making up work must be made as soon as possible.

Extensions / Rescheduling Exams

Rescheduling of exams and extensions on assignments will only be allowed in compelling circumstances (e.g. an excused absence on exam day, or a series of excused absences covering a significant portion of time before the due date). In particular, note that leaving early for a vacation is generally not a compelling reason, nor is being busy or having a bunch of assignments due at the same time.

Arrangements for rescheduled exams or extensions must be made sufficiently in advance of the date in question - waiting until the day or night before a team trip which has been scheduled for weeks is not "advance arrangements". In addition, it is the student's responsibility to ensure that there are actual arrangements in place - simply sending an email about an upcoming absence does not constitute "arrangements".

If arrangements cannot be made in advance (e.g. due to a last-minute emergency), the policy for make-up work applies.

Collaboration Policy

The Principle of Academic Integrity (see the HWS Catalogue, p. 33) governs all of the work completed in this course. In short, this means that anything you turn in for a grade must be your work - your ideas and your effort. Specifically:

You may discuss labs with other students, but you must also:

  • acknowledge, in the assignment write-up, who you got help from and in what capacity (include all sources - other students, tutors, TAs, the instructor)
  • fully understand the help you receive (you should be able to explain your solution to someone else)
  • write up the assignment independently and in your own words (this helps ensure that you really do understand the solution)

Programming assignments are to be completed individually. You may not work with other students in the course in any way, and may not use any resources other than your own notes and course materials (the textbook, handouts, and the course webpage). You may receive debugging help from a tutor or TA, but anything beyond debugging should be referred to the instructor. For any help you receive, you must:

  • acknowledge, in the assignment write-up, who you got help from and in what capacity (tutors, TAs, the instructor)
  • fully understand the help you receive (you should be able to explain your solution to someone else)

Exams are to be completed solely by the student whose name is on the paper. The only person you may discuss the exam with is the instructor, and you may use only those materials authorized in the exam instructions.

Copying part or all of someone else's solution is expressly prohibited, and it is never acceptable to be in possession of someone else's program or solution before you have handed in your own. Decompiling or reverse-engineering provided code is also prohibited.

Failure to acknowledge help received will generally result in a warning the first time, and point deductions for subsequent offenses. Submitting work which is unreasonably similar to another person's work and/or not being able to explain any part of your solution will result in a minimum penalty of a 0 on the assignment. A second such offense is grounds for failure in the course. Plagiarism offenses may also be referred to the Committee on Standards.

There are no exceptions to this policy; ignorance of the policy and desperation ("It was the night before it was due and there wasn't anyone else to ask!") are specifically not excuses for violating the policy. If you are having trouble with the course material, come to the instructor! - it is never advantageous to "borrow" someone else's solution, and the time spent trying to disguise this "borrowing" is far better spent getting help.

Plagiarism in Programs and on Problem Sets

As with papers, verbatim copying of programs and problem solutions constitutes plagiarism. Also as with papers, plagiarism is not limited to verbatim copying - copying the significant ideas and structure of someone else's program/problem solution also constitutes plagiarism.

But aren't all programs which solve the same task/solutions to the same problem pretty much the same, so won't my program/solution look like everyone else's even if I worked by myself?
It is true that programming languages are simpler and more structured than human languages like English, and so two independently-written programs solving the same problem will be more similar than two independently-written papers on the same topic. However, "more similar" doesn't mean "the same" - there is still flexibility in many aspects of the program, and each programmer will express themselves somewhat differently. It is clear when two programs were derived from the same source, and I routinely run a plagiarism-detection tool on all handins.
Problem sets are similar - there is enough room for variation in most solutions for it to be clear when solutions were derived from the same source.

Programming/problem solving techniques are often explained via examples - what's the difference between using an example and "copying the significant ideas and structure"?
Nothing - the whole point of examples is to provide the significant ideas and structure of the solution, with the idea that the details would be modified for the particular situation.

OK, then, so I can't use any examples because that constitutes plagiarism?!
No, not exactly. What is and isn't allowed is a matter of degree. Let's first define "example" and "solution":

  • An example illustrates a technical point or problem-solving strategy, applied to a different problem instance than the one you are trying to solve. An example can't be used as-is to solve your specific problem, but can be adapted to address some aspect of the problem. For example, an example demonstrating the proper syntax for a while loop is OK to use when writing a program which involves a while loop (as long as the point of the problem isn't to write exactly the while loop given in the example).
  • A solution gives a significant amount of the answer to your particular problem (or an extremely similar problem). Quantity is relevant here - you may view something as just an example (because it doesn't solve your exact problem), but if a single source covers most of what you need to do, it may well be what I consider a "solution".

Using "examples" (as defined above) is generally OK but using "solutions" is not.

There's a fuzzy middle ground here, and I'm still not sure exactly what is OK and what isn't.
Then ASK! - before you get into whatever situation you are wondering about. A few additional guidelines which may help:

  • Any materials provided as part of the course (examples in the textbook, from class, and directly posted on the webpage) are acceptable to use/adapt (unless specifically forbidden, such as on exams).
  • Any solutions written by another student (either this term or in previous terms) are not acceptable to use as "inspiration" or a guide when you are working on the same assignment. (Looking at someone else's work later, after the assignment has been handed in, is fine.)
  • Use caution with materials from other sources - think "examples, not solutions" and ask if you have any questions. In fact, ask even if you are sure something is allowed. (Specifically looking through other materials to find solutions to problems you've been assigned is not acceptable.)
  • Use common sense - the purpose of assignments is for you to practice and gain understanding of the material, and for you to demonstrate what you have mastered. If you are mostly just tweaking something written by someone else - even if you spend a lot of time renaming variables and inserting comments - then that is plagiarism.

Center for Teaching and Learning (CTL)

Hobart and William Smith Colleges encourages students to seek the academic collaboration and resources that will enable them to demonstrate their best work. Students who would like to enhance their study skills, writing skills, or have other academic inquiries should contact the CTL. You may visit the CTL web site to learn more about the services and programs that are available.

If you are a student with a disability for which you may need accommodations, you are required to register with the Coordinator of Disability Services at the CTL and provide documentation of the disability. Services and accommodations will not be provided until this process is complete. The web site for information pertaining to registration with the CTL and documenting disabilities is: http://www.hws.edu/studentlife/stuaffairs_disabilities.aspx.

Extra Time on Exams or Other Accommodations

If there's something about the course that would serve you better (e.g. course material in other formats), let me know!

If you need extra time on exams or other accommodations, see the section on CTL above. You must provide me with documentation in advance in order to receive accommodations.

Valid HTML 4.01!