When conducting peer code reviews, fill out the template below in a comment on your peer’s pull request.

# Peer Code Review

## Correctness

The code satisfies the requirements outlined in the project description. Check the box for each requirement that is satisfied (as shown by the images and code changes in the Pull Request):
- [ ] Requirement 1: Student adds a menu item to the IDLE editor under Options that says Show Code Outline
- [ ] Requirement 2: when they have selected/highlighted a region of code, then a user should see the Code Outline for the selected/highlighted lines appear in the IDLE shell
- [ ] Requirement 3: The level of indent should match between the outline and file (i.e., you should be able to process functions outside of classes, functions within functions, etc.)
- [ ] Requirement 4: When a user selects the Show Code Outline option when they have not selected/highlighted any code, then a user should see the Code Outline for the entire Python file appear in the IDLE shell
- [ ] Requirement 5: There should be a keyboard shortcut to invoke Show Code Outline option

### Edge Cases

Please also consider these edge cases for Project 3

- [ ] If the shell is closed, does it open upon clicking Show Code Outline
- [ ] Does Show Code Outline work on commented out functions?
- [ ] Does the shell show the prompt `>>>` after the outline?


## Simple Design

The design of the solution should focus on simplicity, clarity, and maintainability. Students should evaluate whether the code adheres to these principles:
- [ ] Exemplary: The design is easy to understand, modular, and avoids unnecessary complexity. It follows established design principles such as separation of concerns and single responsibility. Functions and classes are appropriately sized, and the logic is straightforward and efficient.
- [ ] Satisfactory: The design is mostly clear and functional but may include minor complexities or redundancies that could be simplified. Some opportunities for better modularization or adherence to design principles exist.
- [ ] Needs Improvement: The design is difficult to follow or overly complex. There are clear violations of design principles, such as tightly coupled components or overly large functions/classes.
- [ ] Missing or None: The design lacks structure or is so poorly implemented that it cannot be reasonably understood or maintained.

### Explain your choice:

Under each bullet point, answer the question and explain your reasoning:
- Are functions/classes too large or trying to do too much?
- Are there unnecessary dependencies or overly complex logic?
- Is the code easy to follow for someone new to the project?

In your answer, do NOT just copy the existing rubric.

### Specifics

Please also respond to the following for Project 3 (select one)

New Class Creation:
- [ ] New file/class for Code Outline
- [ ] Feature implemented within EditorWindow/existing class
- [ ] Other (explain in comments)

Writing to Shell:
- [ ] Code outline text in shell is editable
- [ ] Code outline text in shell is not editable

No functions or classes:
- [ ] Code with no functions or classes output nothing
- [ ] Other (explain in comments)

### Comments:

## Code Style

Code style focuses on readability, consistency, and adherence to coding standards. Students should evaluate whether the code meets these criteria (check one):
- [ ] Exemplary: The code strictly follows established coding conventions (e.g., naming conventions, indentation, spacing). It is well-documented with comments where necessary and variable/function names are descriptive. The formatting is clean and consistent throughout.
- [ ] Satisfactory: The code mostly adheres to coding standards but may have minor inconsistencies in formatting or naming conventions. Comments may be present but could be more detailed, better placed, or may be unnecessary.
- [ ] Needs Improvement: The code has significant style issues, such as inconsistent formatting, unclear naming conventions, or insufficient documentation. These issues negatively impact readability.
- [ ] Missing or None: The code does not follow any recognizable style guide. It is poorly formatted, lacks meaningful comments, and uses unclear or inconsistent names.

### Explain your choice:

Under each bullet point, answer the question and explain your reasoning:
- [ ] Are variable/function names descriptive and consistent?
- [ ] Is the code properly indented and formatted?
- [ ] Are comments used effectively to explain non-obvious logic?
- [ ] Does the code follow the project's style guide?

If there are unused comments, leave an inline comment letting the author know to remove them before merging. In your answer, do NOT just copy the existing rubric.

## Did you (the reviewer) add inline comments (both positive and negative) related to the three categories above? 

- [ ] Yes
- [ ] No

## Would you merge this PR?

*insert your answer here*