Course Policies and Administration

Table of Contents

Exams

There will be one midterm exam and a final exam. The final exam will be during the regular final exam period. Check the registrar's final exam block schedule for date and time (I'll add this to the coures calendar during the term when the registrar releases the schedule.)

Grading

This course is very project based. Your grade is based on our judgement of the quality of your work and the degree of mastery you demonstrate. Written work is especially important. Your final grade will be based on a weighted sum of your homework, quizzes, labs, and exam scores:

Homeworks and labs	70%
Midterm exam	10%
Final exam	20%

This weighting may be adjusted at my discretion.

Although your ultimate course grade will be a conventional letter grade, your homework and other class work will be graded on a scale of No Credit, Fair, Good, Very Good, Excellent. Details are discussed below.

To give you an opportunity to be recognized for truly extraordinary work, Very Good on this scale is roughly in the range of an A; Excellent grades will be assigned only rarely and are reserved for work that is truly exceptional. Work that more more or less meets the full requirements of the assignment but without much flair or extra quality will likely receive a grade of Good, which is roughly a B.

A consistent record of Very Good homework together with commensurate examination grades will lead to a course grade in the A range. If a significant portion of work is rated Excellent, a grade of A+ is possible. Work rated Good corresponds to a wide range of passing grades centered roughly around B. Work rated Fair will lead to low but satisfactory course grades; if a significant fraction of your work is Poor, you can expect an unsatisfactory grade (D or F).

There are more details on homework grading available below in the section on homework.

Getting help

There are many resources available to you to help you with your work in COMP 40.

For most technical questions about COMP 40, try Piazza first (see instructions below).

For general questions about technology (e.g "how do you truncate an existing file in Linux?") you can consult Stackoverflow. We have provided detailed guidelines about how to use it in a way that maintains your integrity and respects the norms of the Stackoverflow community. Please also be aware of the Stackoverflow community guidelines for homework questions.

A large staff of Teaching Assistants is available to help you. (See below for details).

Mark and Megan will be happy to meet with you during office hours, which are listed on Mark's home page and Megan's home page. For personal matters you are always welcome to e-mail them directly.

Teaching Assistants

We have a large staff of undergraduate teaching assistants, all of whom have taken and done well in COMP 40. Generally, teaching assistants can be found in the Halligan 116 and 118 labs. There is a page on Piazza on which we will publicize and update the schedule of which TA's will be working when. We generally use Halligan Helper to manage the queues of students requesting TA help in the labs.

Piazza Forum

We have a Piazza Forum for class discussion. Use this signup link to register yourself before the class begins. For most questions about assignments and the technologies we study, please use the Piazza forum. That way, you will benefit from the expertise of other students as well as that of TAs and teachers. Other students will see your question and the answer.

Anonymous postings and instructor-only postings are allowed but discouraged. It's helpful if students and teachers get to know who has which questions and if everyone discusses problems together. Still, we'd rather you post anonymously or privately than not at all.

There is one important exception: because the course collaboration policy requires that you never publicly post any of the code or other writing that you create as solutions to our assignments, you have two options for asking detailed questions about your own code or designs:

• (preferred) Piazza offers an option to post questions marked "Instructor only". Such postings are available to the professors and teaching assistants but not to other students: posting fragments of your code in this manner does not violate the course collaboration policy.
• If necessary, you can e-mail comp40-staff@cs.tufts.edu

Academic Resource Center (ARC) Subject Tutoring

You also have help available through the Academic Resource Center.

The Academic Resource Center provides free group and one-on-one tutoring for students in Comp40. This a way for students to receive individualized attention on any concepts they are struggling with in the course. ARC tutors do not work on graded assignments, but can help students grasp the ideas underlying a project and think through the problem.

The ARC will be offering drop-in hours as well as weekly one-on-one sessions which you can sign up for through tutor finder on SiS (instructions here). If you have any questions about how the ARC works feel free to email Tal at tal.august@tufts.edu.

An ARC tutor is an additional resource to help reinforce subject material, help you develop effective study strategies, and help you take responsibility for your own learning. More information is available from the ARC website.

Lab scheduling and procedures

This class has a mandatory 75-minute laboratory session. Most of the lab sessions are designed to help you develop key skills or code that you will need to complete your programming projects. Our objective is to get you launched on a problem by providing 75 minutes of guidance and real-time feedback.

Students who registered using SIS chose a lab time when registering. The few students who were admitted later will be given instructions for choosing a lab.

During the term, if you would like to switch to another lab, you may as long as there is space available. We discourage repeated switching but you may change if you have a scheduling conflict or, after the first assignment, if switching is necessary so that you can work with the partner of your choice. This term we are not using an online sign-up system to manage lab changes. Most likely, everything will work out, but if we start having problems with labs that are over-full we will have to resort to a formal sign-up system.

We will use rooms 116 and 118 as our main rooms: use them if there is space available. Use 120 for overflow. SIS may have asked you to choose a room but we don't care which room you are in. You and your partner can choose any available workstation in 116, 118 or 120.

Take notes in the labs. Taking notes helps you remember things — sometimes so that you don't need the notes later. This is better than not getting the reinforcement, forgetting, and then needing the notes. We may also ask you to do pencil-and-paper exercises, which we may collect and grade.

Textbooks

• You will need access to a copy of David R. Hanson, C Interfaces and Implementations before class starts. You'll use it intensively throughout the term, but especially the first few weeks. If you don't mind reading online, you may access the book via O'Reilly's Safari system.

  There is also a PDF quick reference, which will come in handy.

• Kernighan and Ritchie, The C Programming Language, Second edition, ANSI C, is the canonical book about C, and it is one of the best books ever written about any programming language, ever. You can get it used, cheap. If you are serious about software, sooner or later you will want to own Kernighan and Ritchie. But that doesn't mean you have to own it now. We will start using the C programming language intensively on the first day of the course. Be sure you are ready with suitable references.

  You can also get it on-line via O'Reilly's Safari system.

  The Internet has plenty of good information about C, and you may feel there is is no need to buy a book. You're welcome to peruse the sources on the course reference page. You'll need to know how effectively you can work with online information, versus a book you can write in, put stickies on pages of, and so on.

  An alternative reference that I consult for authoratiative answers is C: A Reference Manual by Samuel P. Harbison III and Guy L. Steele Jr. It has tons of detail and documents the C99 standard. Also not required.

• Bryant and O'Hallaron, Computer Systems: A Programmer's Perspective, 3rd edition. The book is useful for following lectures on several topics and for getting more depth than lectures can provide. (Lectures are intense and fast-paced, so many people do have trouble following lectures in real time.) And there are a few topics, like caches and assembly code, which may be hard to understand without some sort of book.

  Bryant and O'Hallaron is an excellent book. We do not absolutely require you to buy a copy and we do not assign exercises from the book. Every year, some students succeed well without it. On the other hand, every year we find students who would have done much better in the course, and especially on the midterm and the final, if they had studied the excellent explanations in the book and made use of the practice exercises. For most students, it will be a good investment.

  For the spring of 2016, we are switching to the third addition. You may use the second edition. The main advantage of the third edition is that the text has been updated to reflect the fact that most Intel architectures are 64-bit, and so the machine and assembly language sections are much clearer and more directly related to your work. If you use the second edition, I recommend getting a hold of the third edition for these readings.

COMP 40 is a time-intensive course. Books that save you time are worth the money.

There are also other suggested supplemental readings

Homework

This is a project-based course. Most work for this course involves programming assignments, and you will learn in detail much of the material on your own as you complete the homeworks and labs. Stated differently: the projects are where you learn to use and get comfortable with the material we introduce in the lectures. The assignments also give you valuable experience as a software developer.

We require that everyone do pair programming during the term. Exceptions are made only in unusual circumstances (e.g your partner drops the course and it's too late to assign another). More information about pair programming in COMP 40 is available in the section on pair programming. Read it! You are responsible for knowing the rules.

Many of the assignments will use software that comes with the text by Hanson or the text by Bryant and O'Hallaron. Some assignments will require you to measure and analyze the way programs behave: how long they take to run, and so on.

These assignments are difficult and you will almost surely need help often. Remember that a short conversation during office hours or with a TA in the lab can save hours of aimless frustration. Use the course Piazza forum.

Your fellow students (except your partner, of course) are not allowed to look at or help you with details of your code (unless the professor gives you permission), but we strongly encourage students to teach each other concepts, programming techniques, details of machine architecture, etc. You will find lots of interesting discussions happening at the whiteboards in the labs.

Information required with every submission

Each programming assignment submission must include a README text file giving he following information:

• Your names (every source or data file as well as every written document you submit must have your names included, except in cases where a data format does not allow for such annotation or in which the file is produced automatically by a program).
• The CS dept login for each partner
• Indication of what aspects of the project have been implemented correctly and what aspects have not been implemented correctly.
• Identify anyone with whom you have collaborated or discussed the assignment.
• Identify what parts of the assignment were done using pair programming, if any, and with whom you were paired.
• Say approximately how many hours you have spent completing the assignment.

Formatting of code and written materials matters

All code you submit will be graded for structure and organization as well as functionality. When you work professionally as a programmer, your work will be used by and modified by others. Although many CS students are tempted to assume that running code is a substitue for clear explanations in English, the converse is typically the case. Many otherwise useful designs or implementations are abandoned because other programmers cannot easily figure out how they work. In short, a solution to a problem is of little value if that solution cannot be understood and modified by others.

For those reasons, your homework will be graded on your presentation of what you are doing as well as your results. For many homeworks, especially those involving substantial programming, half of your grade will be based on presentation. Presentation encompasses the structure and organization of your code as well as comments and other documentation.

Formatting matters. When you submit your work, it should be beautiful, and there should be no question of your dedication to quality. Prepare it as if you were writing up an example for a good textbook. Hint: Just as with a paper for a literature course, the first draft of a program that works is not usually the version to submit.

All of your written work must carry the name(s) and the CS dept login(s) of all members of your pair programming team, and it must be neat and well organized. Any work that cannot be read easily will earn No Credit. Clear English expression is required; grammar and spelling count. The same requirements apply to exams.

Coding Standards

All code submitted for this course must abide by the course coding standards, which are based on the Linux kernel coding standards. This will save your eyesight and ours, and will also give you a feel for professional software development. Many organizations (Apple, Microsoft, etc.) have a “house style” to make it easy for developers to read and work on each other's code. You'll see this during team work, I suspect. Grades will decrease with coding standards violations.

More Detail on Homework Grades

Your homework grades will be based on the course staff's judgement of the quality of your work and your mastery of the material. Grades are assigned on the same scale used by the National Science Foundation:

• Excellent work is outstanding in all respects. To be ranked excellent, the work must truly excel; that is, it must exceed expectations in some way. The normal top grade for work in COMP 40 is Very Good, and students who consistently produce Very Good work earn A's. Grades of Excellent are awarded only in cases of true distinction.

  Excellent documentation will address exactly the key issues, and degree of detail will be exactly appropriate.

  Excellent code will be very well thought out and implemented. Representations and their invariants will be well documented in the code itself. Invariants will be protected by assertions. Excellent code will show evidence of thorough attention to abstraction and modularity. Excellent code will be so simple that it obviously has no faults. Instructors will see no obvious ways to make excellent code simpler or clearer. Layout will be consistent and will make good use of vertical space. Excellent code will be of such high quality that the course staff would be happy to maintain it.

• Very Good work is of high quality in nearly all respects. An assignment that does everything asked for, and does it well, will earn a grade of Very Good.

  Very good documentation will address most key issues, with a good amount of detail.

  In Very Good code, representations will be well documented but some invariants may have been overlooked. Key assumptions (non-null pointers, non-zero divisors) will be validated by assertions. Invariants may be validated. Individual functions will be well organized and readable. Some attention will have been paid to abstraction and modularity, although one or two opportunities may have been overlooked. Nevertheless, very good code will maintain a single point of truth (see Don't Repeat Yourself) for properties of algorithms and data structures. Instructors may see one or two ways to make code simpler or clearer. Layout will be consistent and will make good use of scarce vertical space. Small errors may be evident from reading the code.

• Good work demonstrates quality and significant learning.

  Good documentation will cover some key issues, but significant issues may have been overlooked or may have been covered with insufficient detail. Vague generalities may appear where precise specifics are expected.

  In Good code, representations will be documented, but documentation may not be up to expectations. Some assertions will be present, but perhaps not as many as should be. Individual functions will be well organized and readable. Opportunities for abstraction and modularity will probably have been overlooked: representation may be exposed unnecessarily, too many unrelated functions may have been gathered in one file, or both. Command-line processing may be mixed with program abstractions, for example. The code may not always maintain a single point of truth for properties of algorithms and and data structures, but duplication will be minimal. Good code will get the job done, but possibly in a way that could be shorter or simpler. Layout may be inconsistent in a few places. Errors may be evident from reading the code, but instructors will believe that code could be made correct with only modest changes.

• Fair work is lacking in one or more aspects; key issues need to be addressed. “Fair” is the lowest satisfactory grade.

  Fair documentation will show evidence of effort, but the degree of coverage and detail will be significantly short of what the course staff believe is needed to foster success.

  Fair code will contain significant faults. Representations may be undocumented. Instructors may not be able to figure out what all functions do. Layout may be inconsistent or waste scarce vertical space (e.g., every other line may be blank). Fair code may show evidence of a 'clone and modify' approach to program construction. Possibly a Fair program could be replaced by code half its size. Given Fair code, instructors may believe major changes would be required to make the code correct, or instructors may be unable to understand why the code might be correct.

• Poor work shows little evidence of effort or has other serious deficiencies. “Poor” is an unsatisfactory grade.

  Poor documentation may fail to address key issues or may address them perfunctorily.

  Poor code may be undocumented or inappropriately documented (e.g., overcommented). Poor code will often be lengthy out of all proportion to the problem being solved. Poor code may be laid out on the page in a way that is hard to read. Poor code often shows evidence of its history: extra copies of functions, unused logic left lying around, old code commented out, and so on. Poor code may be so complex that it has no obvious faults.

• No Credit will be received for work not turned in, for parts that are incomplete, or for work that is non-functional or appears to bear no relation to the problems assigned.

  You will receive No Credit for work that you cannot explain.

  No Credit will be received for work that is deemed to be plagiarized. Code submitted for Comp 40 may be examined for potential plagiarism using automated heuristics. Plagiarism is a form of academic fraud, which is unacceptable at Tufts. If academic fraud is suspected, a report will be filed with Judicial Affairs.

Errors, Exceptions, Output, Valgrind and Grades

A program that dumps core, e.g. due to a "segmentation fault" earns No Credit, unless the assignment specifically allows for such failures.

Certain assignments allow for or even require use of Hanson assertions or other Hanson exceptions to signal errors. Often the assignment will refer to these as "Checked Runtime Errors" (CREs), which is Hanson's term. These exceptions and assertions are discussed in Chapter 4 of C Interfaces and Implementations. The default handler that's supplied for such CREs does dump core, but there is no deduction in grade for such core dumps if the assignment allows for the assertions or exceptions. Other core dumps, e.g. due to a segmentation fault, reduce your grade to No Credit.

No credit may result in situations where output to stdout, stderr or other files does not exactly conform the specifications of the assignment. When an assignment requires a CRE, then other forms of error reporting will not be accepted and may result in loss of all credit for that portion of the assignment. Be careful: these sorts of mistakes can easily result in repeated deductions on a single assignment, as it's quite possible that multiple tests will result in such incorrectly reported errors. This is probably the most common reason that students submitting fundamentally sound COMP 40 projects get low grades, but it's also realistic in modeling what's expected of high quality programs: you don't expect to see debugging output appearing on the display screens of the many computer-based products you use! Careful adherence to output specifications is particularly important when the output of your program may be read by another program. In short, producing output that exactly matches specifications is one of the most important things to achieve in your programming work.

Where a the specification allows for or requires termination with a failed assertion or other exception, then any output produced by the default exception handlers is of course allowed.

To earn a grade of Very Good or better, code must run under valgrind without leaks or errors. There are two exceptions (pun intended) to this policy:

1. In situations where the assignment allows termination with a checked runtime exception and where your program actually raises such an exception, memory leaks will not reduce your grade.
2. Certain Hanson ADTs are best used with what Hanson calls Atoms, and the Hanson implementation of Atoms leaks memory. (Even code supplied by professionals can have significant shortcomings, though there are reasons why reclaiming memory for Atoms is particularly challenging. Other programming environments that have similar abstractions frequently have the same problem.) If your only memory leaks trace to (reasonable) uses of Hanson's Atoms, there will be no penalty.

Note: you may find it helpful when checking for leaks to run valgrind with the following options:

      valgrind --leak-check=full --show-reachable=yes <your_program>

To earn a grade of Good or better, code must run under valgrind without errors.

Extra Credit

Some homework assignments will offer opportunities to earn extra credit. Extra credit on homework is independent of the ordinary grade for that assignment; extra credit cannot turn Good work into Very Good or Very Good into Excellent. (Were it otherwise, giving extra credit would amount to nothing more than a sneaky way of assigning more homework.) I use extra credit to adjust final letter grades. For example, if your final grade falls in the borderline between A– and B+, extra-credit work will help me justify the higher grade. I may also mention extra credit if I write you a letter of recommendation.

Extra credit is just that: extra. It is possible to earn an A+ without doing any extra credit.

Late Submissions

Homework will be submitted electronically and will be due at the 11:59 PM on the due date. We will grant an automatic extension of at leat ten minutes and often somewhat more at no cost to you, so the real deadline is no earlier than 12:09 AM the following day. If you plan on submitting your work at midnight, you will have nine minutes for last-minute changes. (Why not advertise an exact grace period? We have found that if we say "10 minutes" we get asked "Oh, it's due 10 minutes after midnight. Surely 12 minutes is OK?" with each advertised grace period becoming the basis for more negotiation and discussion. So, we give you a guaranteed minimum, but reserve the right to accept without penalty submissions received somewhat later. 30 minutes or so has been common in recent terms.)

Homework is expected to be submitted on time. However, we recognize that the exigencies of college life occasionally interfere with on-time submission. If you have difficulty getting homework in on time, you have two options:

• For ordinary difficulties, each student is automatically issued six ``extension tokens.'' By expending an extension token, you can get an automatic 24-hour extension on all deadlines associated with a single assignment. For example, if a design document is due Tuesday and code is due Friday, expending a single extension token makes the design document due Wednesday and the code due Saturday.

  Expenditure of extension tokens is governed by these rules:

  • At most two extension tokens may be expended on any single assignment. This rule enable us to post solutions in a timely manner.
  • When you are out of tokens, late homework will no longer be accepted. It may be returned ungraded, and you will receive No Credit for the work.
• For extraordinary difficulties, such as serious illness, family emergencies, or other extraordinary unpleasant events, your first step should be to make contact with your associate dean for undergraduate education. You must take this step before the assignment is due. Ask your dean to drop me an email or give me a call, and we will make special arrangements that are suited to your circumstances.

Solutions to homeworks will not be placed on the Web until the last assignment is turned in or until the 48-hour deadline has passed.

Regrading

These assignments are complex to complete, and we try hard to grade them fairly and carefully. Still, mistakes do get made, and when that happens we want to know about it. We also want to be sure you understand the reasons for the grade you received. If you suspect we have made a mistake in grading a homework assignment, you have seven days after the return of the assignment to call the mistake to the attention of your TA or instructor. In such cases, we will reassess the entire assignment and assign a new grade. The new grade may be higher or lower than the original grade. You are always welcome to ask for an explanation of the grade you received. For all such questions, email comp40-staff@cs.tufts.edu.

Submission and automatic validation

We expect to provide a submission script for each assignment. By executing

use comp40

you ensure that these scripts are on your execution path. It is very convenient to put this line in your .cshrc or .profile file:

use -q comp40

Without the -q you may have difficulties with scp, ssh, git, VNC, or rsync.

A submission script is named submit40-name, so for example the submission script for the first assignment is called submit40-intro. Normally you should change to the directory in which you have placed your solutions and run the script. Most submission scripts compile your programs and check for compiler warnings or errors. If you get a warning while submitting, fix the errors (i.e. missing files or non-compiling code) and resubmit.

We encourage you to submit work early and often, even if your work is incomplete, so that you have have an independent check that what you plan to submit is what the course staff are expecting. However, once the submission deadline has been reached, we reserve the right to grade the latest of any submissions you have provided to us. So, if you are planning to use tokens, you must not submit preliminary or incomplete versions of your work or we might grade those. In general, we will not grade more than one submission from each pair programming team.

Pair programming

As computing professionals do, you will work together in COMP 40 with other programmers on problems of much greater scope and complexity than those covered in COMP 11 and COMP 15. All students are responsible for understanding and adhering to the following rules and policies relating to pair programming:

There is an FAQ below detailing the most stringent rules regarding pair programming. However, the Comp 40 Code of Conduct should serve as a more specific reference for what you should and shouldn't do when trying to be a good partner in Comp 40.

You may want to read the interesting article titled All I Really Need to Know About Pair Programming I learned in Kindergarden

Test cases may not be shared

Sharing of test cases is not allowed, except in cases where the assignment specifically encourages it. In past years the policy was a little less clear, and some TAs may not be aware of the clarification, but the policy will be enforced. So, you MUST NOT post test cases in Piazza, to GitHub etc.

Developing test cases is a skill that every programmer needs to learn. It's hard. It takes time. You will come to see that your grades in COMP 40 relate directly to how creatively you test your work.

It is not forbidden to use images or data that you find on the Web to test your code, as long as your use is consistent with any applicable copyrights. If, for example, you find a publicly licensed jpeg of a black cat on a dark night and want to use it to test your brighness program, that's fine. What you must not do is develop test cases specifically for your COMP 40 projects, and then share those test cases with other students. Use good judgment in questionnable cases: it's fine to tell people "there are some really interesting JPEGs on Flickr that might be useful"; it's not OK to post "I got a brightness of 3.74 for daffodil.jpeg, what did you get?" If in doubt, don't share or please ask first.

Software/Platforms

You do not need your own computer to do the work in this course. The computers in Halligan Hall have everything you need.

Programming assignments will be in the C programming language and will be evaluated on the department's 64-bit GNU/Linux servers and lab computers. Some assignments may require the use of machines in Halligan 118; you can get there from the servers using ssh lab118x where x is a, b, c, etc. Be considerate of others using the machine in the lab. Use the who command.

For remote access use homework.cs.tufts.edu.

If you need an account for CS machines, please send email to staff@cs.tufts.edu. Ask for bash as your login shell.

Source code should be available for all of the software used in the course. It will therefore be possible for you to work on some assignments using other machines; however, several assignments will definitely require access to this hardware or to other hardware that uses the same instruction-set architecture. Moreover, if we provide test binaries or other tools for you to compare your work against, they will be available only on the CS servers. When possible, we will link these binaries statically so you can use them on other 64-bit Intel Linux systems.

Consult the course reference page for other helpful information.

Accomodations for students with disabilities

The following is Tufts' policy on support for students with disabilities.

Tufts University values the diversity of our students, staff, and faculty; recognizing the important contribution each student makes to our unique community. Tufts is committed to providing equal access and support to all qualified students through the provision of reasonable accommodations so that each student may fully participate in the Tufts experience. If you have a disability that requires reasonable accommodations, please contact the Student Accessibility Services office at Accessibility@tufts.edu or 1-617-627-4539 to make an appointment with an SAS representative to determine appropriate accommodations. Please be aware that accommodations cannot be enacted retroactively, making timeliness a critical aspect for their provision.

In COMP 40, we are dedicated to helping every student to have a successful and rewarding experience. If you have a disability or any other special circumstance that you feel might need special accomodation, please email mmonroe@cs.tufts.edu; msheldon@cs.tufts.edu, or contact Student Accessibility Services.

Collaboration and Academic Honesty

All must read and adhere to the the policies in the Tufts Policy on Academic Integrity.

COMP 40 Collaboration Rules

The following table is presented to students on the first day of the course. It summarizes some of the important rules as to who may help you with your designs, code, debugging, etc.

A few important highlights to note:

• Anyone can help you learn about the languages, machines, technologies and libraries we study. E.g. if you sister is a professional programmer, she can help you learn C, help you understand the Hanson book, and help you write and debug programs to experiment with those technologies.
• Only current course staff, including TAs can look at or help you with the code you develop as solutions to our COMP 40 assignments So, you're sister can help you write a little test main program to experiement with Hanson's Atom_T or Seq_t; she must not look at our help you design, code or debug code that uses those same ADTs as part of the solutions to one of our assignments.
• You and your pair programming partner should of course share work on everything, unless we tell you not to.
• Other students in COMP 40
  • Must not look at your code (except for Makefiles and compile scripts)
  • Must not team up across partner groups to collaborate on solving our homework problems
  • May have limited general discussions of approaches to our assignments.

  So, it's not OK for 6 COMP 40 students to meet with the goal of developing a comprehensive joint design for a program we've assigned; it is OK for small groups of students to discuss the concepts underlying a problem, and to suggest directions for exploration and general approaches to solutions. The line isn't always quite clear. We want to allow you to help each other a bit, to give each other some good hints and help each other over hurdles occasionally, but to ensure that each team ultimately decides on and codes their own solution. It's never OK to read the code developed by another team. It's never OK to submit a solution that isn't understood by all partners on the programming team. If you are unsure what's acceptable, ask the instructor.

Some critical guidance:

Some work you do is to further your understanding. Some work will be used to evaluate your understanding (this work is graded). You may work with other students to further your understanding. Work submitted for evaluation is, unless otherwise stated, to be your work alone. You are bound by the basic principles of academic honesty and integrity.

It is never acceptable to present someone else's work as if it were your own. It violates the basic principle of academic honesty. All work you hand in is to be yours and yours alone, unless there is specific instruction to the contrary.

While you are working on a homework assignment, you may collaborate with other students by talking about the problem or your solution in a natural language (e.g., English), but you may not use any formal language, and especially not program code: high-level discussion is good, but each student must do an individual write-up. In other words, you should not be looking at other people's code (or problem set solutions), and you should not show your programs to another student.

You are encouraged to use the online forum to discuss course-related work, but the same rules apply: discussions should be in English and should not include code that is part of a homework solution.

The prohibition against posting code on on-line fora includes, for example, posting your solutions in a publically accessible location like github. Such postings will be considered vioations of course policy and of academic integrity and will reported to the dean's office.

When programming in a team (we will be doing pair programming in this course), you may, of course share code with your partner(s). In pair programming, you work with a partner under the following constraints:

• When work is being done on the program, both partners are present at the computer. One partner holds the keyboard; the other watches the screen. Both partners talk, and the keyboard should change hands occasionally.
• You submit a single program (or design) under both your names. That work gets one grade, which you both receive.

If circumstances, such as scheduling difficulties, make it impossible for you to work as part of a pair, you may ask the course staff for permission to divide an assignment into parts and to do some parts as a member of a pair and other parts as an individual. Such parts must appear in different files, and each file must be clearly identified as the work of an individual or the work of a pair. Work done jointly by the pair should be submitted by both members of the pair. Files containing joint work must be identical. If you as an individual modify a file containing joint work, and you submit the modified file, that act will be considered a violation of academic integrity.

It is never acceptable to divide an assignment into parts and have some parts done by one partner and other parts done by the other. Submitting work done by someone else as your own will be considered an egregious violation of academic integrity. Submitting individual work as the product of pair programming is also a violation of academic integrity.

We may revoke your pair programming priviledge if you engage in unacceptable behavior:

• Repeatedly failing to keep appointments with your partner
• Lying to your partner about what you have done
• Violating academic intergrity
• Other similarly egregious offenses

If I find it necessary to revoke your pair-programming privileges and you believe I have done so unfairly, you may appeal to the department chair.

When you turn in an assignment, you must list all other students with whom you collaborated. If you get significant help from any of the course staff, including a TA, you should acknowledge that, too. Academic honesty requires it. If you are not sure what constitutes collaboration or significant help, err on the side of caution. Giving others credit is good, and they will appreciate it, too.

You may consult public literature (books, articles, the web, etc.) for hints, techniques, etc. However, you must reference any sources that contribute to your solution.

Assignments, exams, solutions and even notebooks from previous terms' versions of this course are not considered to be part of the public literature. You must refrain from looking at any solutions from previous versions of the course (unless that information is distributed this semester).