# Project 00 Code Review Script

This document is intended to guide what happens at the first code review.  
You are allowed to go on tangents, but it's really important you cover everything in this document.

## Before Meeting with the Students
You should skim through the student code before the students show up.  This should take no more than 5 minutes,
but the goal is to identify **three** things you want them to improve before the next code review.  Prioritize the issues
that are systemic and relevant to more than just the actual code they wrote.  Avoid focusing on minor style points  as much
as possible--in favor of trying to help them learn how to **design** their code effectively. Fundamentally, they should
believe that the issues you pointed out are worth fixing, and feel like the code review was worth their time. 
Make sure to write these things down during the code
review using Upsource (the code review tool we will be using).  You might want to make notes to yourself about what you
want to make sure to cover as it's easy to go off on tangents.  FOR THIS CODE REVIEW ONLY, THEY DO NOT ACTUALLY HAVE TO
IMPLEMENT YOUR FEEDBACK.  You should, however, tell them, in the future, part of their grade depends on implementing the
feedback.

## While Meeting with the Students
One of the major goals of doing in-person code reviews is to **discuss** the feedback with the students.  They are allowed
to push back, and you need to have justification for whatever you're asking them to change.  DO NOT LET ONLY ONE STUDENT
TALK DURING THE CODE REVIEW.  THEY MUST ALL PARTICIPATE. Your discussion should focus on the following areas.  These are **in
order** of priority.  If they have a lot of issues, you may not get to all of the categories, and that's okay.

### Correctness
- Did they pass the provided tests?
- Are they passing on gitlab? 
- Do they have memory leaks?  
- Do they have illegal memory accesses?
- Do they handle edge cases?

### Testing
- How did they test their code? (did they run it? just blindly apply the tester? etc.)
- Is there an edge case that they can think of that they either explicitly handled or know their code fails on?

### Design
- Is everything in main?  How could they modularize the code to make it more usable and readable?
- Did they plan out what they were going to write before diving in?  Discuss pros and cons of each approach.

### Readability
- Is the code commented?  
- Is the code "self-documenting"?
- Could another student pick up the code and modify it as necessary?

### Extensibility
- Imagine you had to modify your longest word code to output the shortest word.  What would the changes look like? Is there anything you would have done
  differently if you knew you had to write both in advance?
- Imagine wc had to count both words and lines.  What would the modifications look like?  Is there anything you would have done differently if this
  had been an up-front requirement?

### Teamwork
SKIP THIS SECTION FOR THE FIRST CODE REVIEW

## After Meeting with the Students
After meeting with the students, you should write up a short paragraph of how the review went and assign a preliminary grade for their code
review portion of the grade.  Great answers during the code review can make up for lackluster code.  You should assign one of the following three
grades to this portion:
- (+) Their code was great.  You made minor suggestions, but you'd be happy to pick up their code and work with it.
- (✓) Their code had some issues, but was well designed.  OR Their code had issues, but their answers during the code review indicate they know what they
      should have done instead.
- (-) Their code had some systemic issues AND their answers during the code review indicated they put in a minimal amount of effort. They should probably
      talk to Adam.