# Code Review Quiz

## Question 1

What should you prioritize when reviewing code?

A) Style and formatting first
B) Correctness, then readability, performance, security
C) Whatever the author asks you to look at
D) Only security issues

<!-- ANSWER: B -->
<!-- EXPLANATION: Correctness is the foundation — does it work? Then readability (can others maintain it?), performance (will it scale?), and security (is it safe?). Style matters but shouldn't block merge for minor nits. -->

## Question 2

A reviewer wrote: "Use a better variable name." What's wrong with this feedback?

A) Nothing — it's clear enough
B) It's too vague; the author doesn't know what to change or why
C) Reviewers shouldn't comment on variable names
D) It should be marked as blocking

<!-- ANSWER: B -->
<!-- EXPLANATION: Good feedback is specific and explains why. "Use a better variable name" doesn't say which variable or what "better" means. Something like "Rename `x` to `userCount` for clarity" is actionable. -->

## Question 3

You're about to merge a PR. The tests pass, but you noticed a potential null reference when `data` is undefined. What should you do?

A) Merge anyway — tests pass
B) Request changes and block merge until it's fixed
C) Merge and file a follow-up bug
D) Leave a nit comment and merge

<!-- ANSWER: B -->
<!-- EXPLANATION: Potential null references can cause runtime crashes. If tests pass but don't cover the null case, that's a gap. Blocking merge prevents shipping a bug. Nits are style preferences; correctness issues are blocking. -->

## Question 4

Which PR description is most useful for reviewers?

A) "Fixed the bug"
B) "Updated validation logic per ticket #123"
C) "What: Add login validation. Why: Prevent empty submissions. How: Client-side check before API call; server re-validates."
D) "See the code"

<!-- ANSWER: C -->
<!-- EXPLANATION: A good description explains What (the change), Why (the reason), and How (implementation notes). This gives reviewers context to verify the approach and spot issues. Vague descriptions slow reviews. -->

## Question 5

When receiving critical feedback, what's the most constructive response?

A) "I'll fix it" (no further discussion)
B) "I disagree because [reason]; can we discuss?"
C) Ignore the comment and merge anyway
D) "That's not how we do it here"

<!-- ANSWER: B -->
<!-- EXPLANATION: Disagreeing thoughtfully is fine — explain your reasoning and invite discussion. Option A is acceptable but might miss learning. Options C and D are unprofessional and can escalate conflict. -->

## Question 6

Drag these PR lifecycle steps into the correct order:

<!-- VISUAL: quiz-drag-order -->
<!-- Items: Author addresses feedback, Reviewer approves, Author creates PR, Reviewer requests changes, Merge -->

A) Author creates PR → Reviewer requests changes → Author addresses feedback → Reviewer approves → Merge
B) Author creates PR → Reviewer approves → Merge → Author addresses feedback
C) Reviewer requests changes → Author creates PR → Merge
D) Author addresses feedback → Author creates PR → Reviewer approves → Merge

<!-- ANSWER: A -->
<!-- EXPLANATION: The standard flow: author creates PR, reviewer reviews and may request changes, author addresses feedback, cycle repeats until reviewer approves, then merge. -->

## Question 7

<!-- VISUAL: quiz-drag-order -->

Put these code review process steps in the correct order:

A) Reviewer reviews code
B) Author pushes commits addressing feedback
C) Author requests review
D) Reviewer approves or requests changes
E) Merge to main branch

<!-- ANSWER: C,A,D,B,E -->
<!-- EXPLANATION: Author requests review, reviewer reviews the code, reviewer approves or requests changes. If changes are requested, author pushes updates and the cycle repeats until approval, then merge. -->

## Question 8

<!-- VISUAL: quiz-matching -->

Match each review feedback type to its best practice:

A) Correctness issue → 1) Block merge until fixed; explain the risk
B) Style nit → 2) Suggest improvement but don't block; explain why it helps
C) Security concern → 3) Request changes with clear reproduction steps
D) Performance concern → 4) Flag as blocking; provide remediation guidance

<!-- ANSWER: A3,B2,C4,D2 -->
<!-- EXPLANATION: Correctness issues need clear reproduction steps and block merge. Style nits are suggestions. Security concerns block merge and need remediation. Performance concerns may block or be suggestions depending on severity. -->