# Clean Code Quiz

## Question 1

What is the primary benefit of intent-revealing names?

A) Shorter code
B) Less need for comments; code explains itself
C) Faster execution
D) Fewer bugs from the compiler

<!-- ANSWER: B -->
<!-- EXPLANATION: Good names make code self-documenting. A reader can understand what the code does without comments. This reduces cognitive load and maintenance cost. -->

## Question 2

When should you extract a block of code into a separate function?

A) Whenever a block is longer than 5 lines
B) When it represents a distinct abstraction or single logical task
C) Never — more functions mean more complexity
D) Only when you reuse it in two places

<!-- ANSWER: B -->
<!-- EXPLANATION: Extract when the block does one thing that can be named. Length alone isn't the criterion — a 20-line function that does one thing may be fine. Reuse is a bonus, not the only reason. -->

## Question 3

What does DRY stand for?

A) Don't Repeat Yourself
B) Do Recursive Yields
C) Dynamic Run Yields
D) Data Replication Yearly

<!-- ANSWER: A -->
<!-- EXPLANATION: DRY = Don't Repeat Yourself. The principle says every piece of knowledge should have a single representation. Duplication breeds inconsistency when one copy is updated and another isn't. -->

## Question 4

When is a comment preferable to self-documenting code?

A) Never — comments are always bad
B) When explaining *why* something is done, especially non-obvious business rules
C) When the code is complex
D) When the function is long

<!-- ANSWER: B -->
<!-- EXPLANATION: Good comments explain *why* — business rules, workarounds, legal requirements. Bad comments explain *what* — that's the code's job. If code can be clear, prefer refactoring over comments. -->

## Question 5

What is a "guard clause"?

A) A security check
B) An early return that handles invalid/edge cases before the main logic
C) A type check in TypeScript
D) A unit test

<!-- ANSWER: B -->
<!-- EXPLANATION: Guard clauses are early returns (e.g., if (!valid) return;) that handle edge cases first. They reduce nesting and make the happy path more prominent. -->

## Question 6

Which is a code smell indicating a function may do too much?

A) The function has 2 parameters
B) You need "and" to describe what it does
C) The function returns a value
D) The function uses a loop

<!-- ANSWER: B -->
<!-- EXPLANATION: If you can't describe the function without "and" (e.g., "validates and saves and sends email"), it likely has multiple responsibilities and should be split. -->

## Question 7

<!-- VISUAL: fill-blank -->

Complete the refactored function with a guard clause:

```javascript
function processOrder(order) {
  if (___0___) return null;
  return calculateTotal(order.items);
}
```

<!-- ANSWER: !order -->
<!-- EXPLANATION: A guard clause checks for invalid input early and returns. !order handles null or undefined; it's the inverse of a validity check. -->

## Question 8

<!-- VISUAL: fill-blank -->

Complete the intent-revealing name for a function that validates and formats a user's email:

```javascript
function ___0___(email) {
  if (!email || !email.includes('@')) return null;
  return email.trim().toLowerCase();
}
```

<!-- ANSWER: validateAndFormatEmail -->
<!-- EXPLANATION: The function both validates (returns null if invalid) and formats (trim, lowercase). The name should reveal both intents. Alternatives like normalizeEmail are valid if they convey the same. -->