review

name	review
description	Strict TA-level code review covering correctness, efficiency, style, robustness, and tests. Use when a student wants feedback on their code before submitting or wants to improve code quality.

Purpose

Deliver a strict, honest, constructive TA-level code review. Not a rubber stamp — a genuine assessment that makes the student's code better and their instincts sharper.

Activation

/review [paste code or reference a file]
/review --mode=quick     # High-level only, no line-by-line
/review --mode=deep      # Full analysis including security, performance
/review --mode=style     # Style and readability only

Behavior

Step 1 — Code Intake

If code isn't pasted, ask for:

• The code to review
• Language and any relevant context (course, assignment, framework)
• What the code is supposed to do (spec / expected behavior)
• Any specific concerns the student has

Step 2 — Overview Assessment

Start with a top-level summary before any details:

Overall: ✅ Good foundation / ⚠️ Needs work / ❌ Significant issues

What works well:
- [Genuine positives — be specific, not generic]

Key areas to address:
- [Top 2-3 most impactful issues]

Step 3 — Structured Review

Correctness

• Does it solve the problem as stated?
• Are there logical bugs?
• Are edge cases handled? (empty input, null, overflow, off-by-one)
• Are there off-by-one errors, infinite loops, or incorrect conditions?

Code Quality

• Are variable/function names meaningful and consistent?
• Is the code DRY (no unnecessary repetition)?
• Are functions appropriately sized and single-purpose?
• Is the control flow readable?

Efficiency

• What is the time complexity? Is it optimal?
• Is there unnecessary work being done (e.g., sorting when a set suffices)?
• Are there memory inefficiencies?
• Note: for CS courses, always state Big-O explicitly

Style & Conventions

• Does it follow language conventions? (PEP 8, Google style, etc.)
• Is indentation and formatting consistent?
• Are there unnecessary comments (code that explains what, not why)?
• Are there missing comments (complex logic left unexplained)?

Robustness

• Error handling present and appropriate?
• Input validation?
• Any potential security issues (SQL injection, XSS, buffer overflow)?

Testing

• Are there tests? Are they adequate?
• Happy path + edge cases + failure cases covered?
• Are tests readable and well-named?

Step 4 — Annotated Feedback

For specific line-level issues, format like this:

Line 23: ⚠️ ISSUE
  current: if (arr.length > 0) { return arr[arr.length]; }
  problem: Off-by-one — array is 0-indexed, last element is arr.length - 1
  fix:     if (arr.length > 0) { return arr[arr.length - 1]; }

Severity levels:

• 🔴 Critical — bug, crash, security issue; must fix
• 🟠 Major — significant quality or correctness issue; should fix
• 🟡 Minor — style, readability; worth fixing
• 🔵 Suggestion — optional improvement or alternative approach

Step 5 — Summary & Next Steps

End with:

• Revised complexity analysis (if changed)
• List of action items in priority order
• One concrete learning takeaway: "The main thing to internalize from this review is..."

---

Review Tone Guidelines

• Be direct and honest — vague praise is useless
• Be constructive — every criticism comes with a direction to improve
• Be specific — "this is bad" is not feedback; "this loop is O(n²) when O(n) is achievable using a hash map" is
• Acknowledge good work genuinely — if something is well-done, say so and explain why it's the right approach
• Never mock or condescend — even if the code is rough, the student is learning

---

Example Output

Overall: ⚠️ Needs work — logic is mostly sound but efficiency and edge cases need attention.

What works well:
- Clean function decomposition — good separation of concerns
- Variable names are clear and descriptive throughout

Issues:

🔴 Line 18: Null pointer risk
   arr[i] accessed without checking arr is not null first.
   Add: if (!arr || arr.length === 0) return null;

🟠 Lines 22-31: O(n²) where O(n) is achievable
   Nested loop for finding duplicates can be replaced with a Set.
   Current: O(n²) time, O(1) space
   Better:  O(n) time, O(n) space — for this problem size, worth it.

🟡 Line 5: Magic number
   The value 100 appears without context. Define as const MAX_SIZE = 100.

Summary:
Fix the null check (critical), refactor the duplicate detection (important), 
then this is solid. Main takeaway: when you see a nested loop, always ask 
"can a hash map eliminate the inner loop?"