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).
    • Consistent good timeliness (on-time submissions, majority of core functionality passing in original submission, swift resolution of outstanding issues)
    • 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).
    • Ok timeliness (within grace period, all Priority 1 issues eventually resolved by Assignment 7)
    • 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: Hitting the above metrics is guaranteed to land a course grade in A range or B range respectively. However, there are also other means to demonstrate success and mastery of the course learning goals and achieve noteworthy outcomes – the course staff may decide on areas of flexibility to apply to all students at the end of the quarter. We see your accomplishments and want to reward you!

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. An ontime submission earns a small bonus in timeliness. Kudos to you for pacing your work and shipping on schedule!
  • 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, but they do not earn the timeliness bonus.
  • 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, no citation needed:

  • Peer discussion about course topics, tools, techniques

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

  • Use of our course materials

    Our materials (lectures, labs, website, etc) have lots of useful code examples. Please use and build on these examples!

  • 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.

  • 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.

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 test on oddball cases like free(NULL)"), please cite.

  • Receiving help from an AI acting IFF in the role of "ethical tutor"

    Use of AI tools (e.g. ChatGPT, CoPilot) is restricted to the kind of help that could be provided by a ethically-minded tutor. A good tutor can answers questions about your confusions, can provide clarification, can walk you through an example, can direct you to additional information, and so on. A tutor is acting as a sounding board for your own understanding and guiding without overly leading. If you used an AI as a tutor, you should cite the assistance you received. Note that a properly-trained tutor doesn't write code for you nor does it point out your bugs or tell you how to rewrite your code. Such uses are disallowed.

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. Put your citations either in a README.md or as comments in your code, either at the top of the file or next to the function/line for which you received help.

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 or AI tools for help with assignment-specific code

    You should not be searching online for assignment solution code. Should you stumble across some accidentally, the correct response to about-face. You should not request assignment-specific code from external sources (e.g. StackOverflow) nor should you be using an AI tool (e.g. ChatGPT, CoPilot) to generate code for you or fix/debug your code.

  • 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.