Course Policies


Grading Policy

Your course grade comes from your efforts in lab, assignments, and the final project.

  • Labs meet weekly, your attendance and participation is mandatory.
  • There are 7 weekly assignments. The assignment specification identifies the core features which are required, along with optional extensions where you can go above and beyond.
  • The course culminates with a final project where you design and implement a system of your choosing.

If you have your sights set on earning an A course grade, you will need consistently outstanding work:

  • Attend and participate in all labs.
  • Assignments (how assignments are graded)
    • Core functionality is complete/correct:
      • Passing all Priority 1 and Priority 2 tests for all assignments (revise and resubmit ok).
    • Significant Core functionality is completed on time:
      • By end-of-grace-period for a given assignment, >70% P1s must be passing.
    • Code quality (style and tests) trending to +.
    • 3 or more assignment extensions successfully completed.
    • Earn the full system bonus for using all your own code on the last assignment.
  • Outstanding final project, excellent execution.

For a B course grade, we expect consistently solid work:

  • Attend and participate in all labs.
  • Assignments
    • Core functionality is mostly complete/correct:
      • Passing all Priority 1 tests for all assignments (revise and resubmit ok).
    • Code quality (style and tests) trending to ok.
    • One extension attempted or full system bonus earned.
  • Good final project, satisfactory execution.

Work that is not completed satisfactorily will earn grades C and below.

NOTE: The metrics above will guarantee that you receive an A range or B range respectively. However, they are guidelines and it is possible to get an A in other ways – the course staff may decide on areas of flexibility to apply to all students at the end of the quarter. In other words, these are “sufficient but not necessary.”

Late Policy

The course moves at a steady clip and the weekly assignments build on one other. In our experience, one of the strongest factors in student success has been the dedication to stay on pace. Learning to set a schedule and manage your time to hit deadlines is a valuable skill to develop and an accomplishment you can be proud of. We designed our policy to encourage and reward good habits, but knowing that things come up, we have a standing grace period that provides a little flexibility if you need it.

  • The submission deadline for the weekly assignments is 5pm Tuesday.
  • There is also a 48-hour grace period after the deadline in which we accept late submissions. There is no penalty or cap applied to late submissions within the grace period.
  • Late submissions beyond the grace period are arranged with the course staff as warranted for exceptional circumstances.
  • The final project must be submitted on time without exception.

Collaboration Policy

Adapted from CS107 policy by Julie Zelenski, some wording borrowed from a collaboration policy distributed by Brown CS.

Programming is a skill that can only be learned by doing. The assignments will require significant dedication from you, but we hope the time you spend will be fun, challenging, illuminating, and rewarding. Your pride upon finishing is a fantastic high and your efforts earn you powerful skills and deep understanding. Don't cheat yourself out of this incredible learning opportunity! Borrowing someone else's design, building on another's code, being lead by another person, and other such "shortcuts" jeopardize the chance to develop your own mastery and compromise your integrity.

All of you should be familiar with the principles of the Stanford Honor Code. The CS 106 policy further explains how it applies in programming courses. Students are to uphold their obligations to do honorable work and encourage others to do the same. On our part, we will treat students with trust and respect.

Assistance that is allowed

These things are encouraged and allowed for all students:

  • Peer discussion about course topics, tools, techniques

    Please do discuss all content from lectures, lab, readings, ask and answer questions about C and ARM, exchange tips for effective use of tools, and share useful resources. Talking things through with your peers can boost everyone's learning!

  • Use of external resources for background information

    You may search for and use external resources (web sites, blogs, forums, etc.) to further your understanding of course topics, languages, and tools.

  • Discussion with staff

    If you need to help with an issue specific to your design/code/debugging, please bring to the course staff. They are deeply knowledgeable of the course material and know how to guide without overly leading you.

Assistance that must be cited

Discussion specific to the particulars of an assignment should be cited. The particulars include the program's design, data structures, choice of algorithms, implementation strategies, testing, and debugging. Some examples:

  • Discussing your assignment design

    Design is a crucial part of the development process, and we expect you to create a design on your own. Two students who have already each completed their own design could compare and contrast approaches. Both should cite this discussion.

  • Helping another student to debug

    A student might describe symptoms to a peer who responds with suggestions (e.g. "it sounds like you might have forgotten to terminate the string" or "have you tried running under the gdb simulator?"). If you receive debugging help that was essential to your progress, please cite it.

  • Sharing test strategies or cases

    If you discuss strategies for testing or jointly brainstorm test inputs (e.g. "be sure to verify handling when index is out of range"), please cite.

What is an appropriate citation?

A citation should be specific, complete, and truthful. Clearly identify the source of the help/discussion (person's name, book title, URL), describe the nature and extent of the assistance, and indicate how it influenced your submission.

Assistance that is NOT allowed

Discussions should never become so detailed that they involve studying or exchanging passages of code. You should never be intimate with another's code nor allow others to be intimate with yours. Here are some specific examples of unpermitted aid:

  • Copying code

    It is plagiarism to submit work as your own which is whole or in part copied or derived from the work of others .

  • Reviewing the code of another

    You may not have another person "walk you through" their approach nor may you use their work "as a reference" to look at if you get stuck.

  • Joint development/debugging

    Students may not jointly work together to develop a design, write code, or debug.

  • Use of external resources for assignment-specific code

    Your code must not be adopted from or influenced by study of any external resource.

  • Sharing your code

    You must not share your code with other students nor publicly post it. After completing the course, you are expected to take reasonable security precautions to maintain your work privately.

Integrity as community

The Honor Code is a powerful assertion that we as a community proudly dedicate ourselves to upholding the highest standards of academic integrity. The vast majority will do right by CS107e – we ask a lot of you and you will consistently meet those challenges in submitting your own authentic work. We demonstrate our respect and appreciation for your integrity by clearly stating our expectations and holding accountable those students who act outside the policy.