Policy on Academic Integrity and Collaboration
By taking this course, you agree to abide by the honesty policy. This governs what kinds of collaborative work you may do.
The purpose of assignments in this class is to help students learn key ideas in programming languages. Some (not all) assignments require a certain insight, or at least careful analysis, that is much harder to generate or perform than to merely replicate. We believe that doing it for yourself, though harder, is the only way to truly understand that insight or analysis.
You will do most assignments in this course in a team. For those assignments, you can and should work collaboratively with your team members, but you may not communicate in any way about the homeworks with members of other teams. You may be on multiple teams at the same time; be careful to keep these identities separate. On solo assignments, you must work entirely alone. Under no circumstance may you have a discussion outside your (single or multi-person) group that makes a task significantly less challenging as a result of the discussion.
The only permissible communication outside the above guidelines is with course staff. If ever in doubt, ask the professor, even if it's after a possible violation. Ignorance is no defense.
We will not be publishing a day-by-day lecture schedule for this course. A day-by-day schedule doesn’t make sense given that some lectures will invariably run over or will need revisiting, and it’s hard to predict a priori which ones these will be. As a student, you should prefer a schedule that doesn’t force the professor to move on irrespective of whether or not you have understood the material well enough!
For the assignment schedule, consult the assignments page.
You are responsible for keeping track of all assignments and other material posted to the course’s newsgroup, brown.cs.cs173, and to its Web site. Please read the newsgroup regularly, because we will post notification of major changes to the Web site there.
Assignment Due Time
Assignments are always due at 2:00AM on the listed date. Why 2AM? Because we want you to attend class and to be reasonably alert when you do so. Past experience indicates that making assignments due at the start of class leads to a largely somnambulist audience that day. Those classes are fun for neither the student nor the professor.
Turning in Assignments
Submit programming assignments via WebCT. For team programming assignments, each member of the team must submit the solution set and specify the team.
For written assignments, print or neatly write your solutions and put them in the handin bin on the second floor of the CIT. Both partners need to submit a dummy (empty) file to WebCT.
- For both written assignments and essays, write your login at the top of every page (this is helpful in case the pages become separated), staple the pages together, and place them in the cs173 handin bin on the second floor of the CIT. Teams need only turn in one hard copy of their solution.
- For written assignments, please solve each problem on a separate page and print single-sided, so the TAs can easily divide your work for grading.
- For team assignments, each member of the team should turn in a complete copy of the team’s work using the correct procedure from above.
We will not accept late assignments. Assignments are often timed to be due for a classroom discussion on the assigned material because you can better follow a difficult topic if your struggles are fresh in your head. The class will sometimes even discuss solutions to the homework problems. Once we do this, we can no longer accept your solution.
If you really need or want to turn in an assignment late, you must get the professor’s permission to do this at least 28 hours before the assignment deadline. (Why 28? Because the professor is unlikely to read email past 10pm.) When we do accept a late submission, we will use this formula to compute your net grade:
(define (net-grade gross-grade number-of-penalty-units) (* gross-grade (expt 0.9 number-of-penalty-units)))A penalty unit is a 24 hour period or part thereof after the due time. Even a minute after the due time incurs a penalty unit. So if you have permission to handin late, relax; sleep; attend class; and submit something polished later in the day.
Team Project Instructions
This year, most of the assignments for this class will be done in teams (pairs, with a single triple if enrollment is an odd number). Our assignments tend to be short on code but long on thinking, so this will give you the opportunity to fully discuss a solution with another person. You will work with four different people over the course of the semester.
Programming in teams does not mean each person writes part of the code and the team simply pastes together these contributions. Each person is responsible for every line of code, documentation, etc. turned in. This responsibility extends over written assignments as well. It includes getting or losing points for quality, being able to explain the work, and also incurring penalties in case of plagiarism or other violations. That said, we will sometimes ask you questions individually and, if you are unable to answer them, we may give you less credit than your teammates. In short, working is teams is meant to help you learn material better, not to enable you to do less work than you would have if the assignment had to be done individually.
For team projects, you may not discuss the assignment with a student not on your team.
Since each team member must separately run the handin script for each programming assignment, we consider running the script the equivalent of signing the code. By handing in code, you acknowledge your responsibility for it in its entirety. Be sure your teammate has not changed or added anything without your knowledge prior to handing in.
We recommend that teams develop the software together using pair-programming techniques (of the form preached by Extreme Programming), though this is a suggestion, not a requirement. Pair-programming in a nutshell:
- Both programmers share a single computer, monitor, and keyboard.
- One person is the typist, the other watches what is being typed and critiques it.
- Programmers switch roles at regular intervals. (Note that this is also good for preventing RSI!)
- Both programmers jointly own every single line of code, regardless of who typed it.
Assignments are broken into groups. You will work with the same team for every assignment in a single group, and you may not work with anyone you worked with in a previous group. Once you have selected a partner please inform the course staff. If you are having difficutly finding someone to be your partner, please contact the course staff, and we will attempt to match you with another student.
We are very serious about requiring you to write clean, well-documented code. 20% of your grade for programming assignments will depend on your design, style, and comments. Since we expect that you document and test your code anyway, we think of this as giving you a free 20% for each assignment.
Not already knowing Scheme or having learned Scheme with a different style are not excuses for not following these requirements. We are using the coding style from How To Design Programs for this course.
- All functions must have a purpose statement that fully explains, in a sentence or two, what the function does.
- All functions must have contracts.
- If you need to use a new type, define a new datatype to represent it. Do not overload lists. Understand the difference between lists and datatypes. Lists are homogenous collections of unlimited extent. In contrast, datatypes are heterogenous collections with a fixed number of members.
- As a general rule, all functions should be no longer than
what fits on a screen. We will of course relax this for
functions with a lot of pattern matching (
parsecomes to mind) and in that case recommend that each match case fits on a screen.
- Assume that your reader understands Scheme, so, in any inline
comments, explain why you wrote the code, don’t explain
what you wrote. We consider
define-typeto be self-documenting.
- Only use Scheme primitives that we have taught in this course. For
cdr. Likewise, use
All functions must have tests that exercise non-trivial cases. We require this to encourage good software development skills, but, more importantly, to force you to show us that you know what your code is supposed to do and that you’re not getting a correct answer by guessing. We will not give full credit to untested functionality, even if it is correct!
Good test cases:
- Test a single aspect of a single feature. Therefore, you will need multiple test cases per feature to ensure its correctness.
- Actually test the program. Testing means not only executing the program but also checking the output to ensure it is what you expected.
- Have a comment to explain their purpose.
We will use codewalks, a common practice at software companies, to evaluate some of your programs and written assignments. Read more…
Please see our page on this.