Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Clean Code Purpose​

Why is clean code mainly about changeability rather than beauty?

Answer: Because the main cost of software is usually in later edits. Clean code lowers the time and risk of understanding, reviewing, testing, and safely changing behavior.

Question 2: Meaningful Names​

Rewrite this code to reveal intent more clearly:

def proc(d):
    for x in d:
        if x["s"] == "A":
            send(x["e"])

Answer: One reasonable rewrite is:

def send_activation_emails(active_users):
    for user in active_users:
        if user["status"] == "ACTIVE":
            send(user["email"])

The improvement is not only longer names. It makes role, condition, and action explicit.

Question 3: Comments​

When is a comment justified even in otherwise clean code?

Answer: When it explains something the code alone cannot express well, such as business rationale, legal constraints, external system quirks, or a dangerous non-obvious tradeoff. It should explain why, not restate what.

Question 4: Function Design​

What are two signals that a function probably does more than one thing?

Answer: Examples include mixed abstraction levels, long parameter lists, boolean control flags, visible multiple phases that need comments, or a name that hides significant side effects.

Question 5: Side Effects​

Why is this function misleading?

def get_total(cart):
    cart.last_accessed_at = now()
    return sum(item.price for item in cart.items)

Answer: The name suggests a query, but it mutates state too. The surprise side effect makes the function harder to trust and reason about.

Question 6: Error Handling​

What is wrong with this pattern?

def parse_config(path):
    try:
        return json.loads(open(path).read())
    except:
        return {}

Answer: It catches everything, hides the reason for failure, and silently returns a potentially misleading default. Better designs separate the happy path from failure handling and preserve meaningful context.

Question 7: Tests​

Why can dirty tests be almost as harmful as having no tests?

Answer: Because messy tests become expensive to maintain. Teams start to fear or ignore them, then lose the safety needed for refactoring, and the production design starts to rot.

Question 8: Classes​

What is a better way to judge class size than counting methods or lines?

Answer: Count responsibilities and reasons to change. A class is too large when it serves unrelated purposes or needs and, or, or but to explain what it does.

Question 9: Refactoring​

Why is successive refinement safer than a one-shot rewrite?

Answer: It breaks cleanup into small verified steps, which makes mistakes easier to detect, reverse, and understand. The system stays stable while structure improves.

Question 10: Review Heuristics​

What makes a code-review comment actionable instead of vague?

Answer: It names the concrete issue and the maintenance risk. For example, "this duplicates the validation rules in two places, so the next rule change can drift" is actionable. "This feels messy" is not.

Interleaved Review Questions​

(5 questions from Modules 1-2 to maintain retention)

Prior Module Question 1: Algorithm Intuition (Module 1)​

What is the key insight that makes binary search faster than linear search?

Answer: Each comparison eliminates half the remaining possibilities because the data is sorted, leading to O(log n) instead of O(n).

Prior Module Question 2: CS Fundamentals (Module 2)​

What is the difference between syntax and semantics in programming languages?

Answer: Syntax is the grammatical rule set for what code is valid. Semantics is what that valid code means and how it behaves when executed.

Prior Module Question 3: Big-O Analysis (Module 1)​

Why do we ignore constants and lower-order terms in Big-O analysis?

Answer: Big-O tracks dominant growth as input size becomes large. Higher-order growth eventually dominates the rest.

Prior Module Question 4: Computational Thinking (Module 2)​

What are the four key components of computational thinking?

Answer: Decomposition, pattern recognition, abstraction, and algorithm design.

Prior Module Question 5: Systems Thinking (Module 2)​

How do abstraction layers in computer systems both help and create problems?

Answer: They help by hiding lower-level complexity and making higher-level work possible. They create problems when hidden details leak and you must reason across layers to debug or optimize.

Self-Assessment​

  • 90%+ correct: Ready to advance to Semester 1
  • 70-89% correct: Review weak areas and redo at least one practice page
  • <70% correct: Revisit clean code concepts and apply them to an existing code sample

Semester 0 Integration Check​

Before advancing to Semester 1, verify integration across all 3 S0 modules:

Cross-Module Integration​

  • Algorithm Intuition + Clean Code: Implement algorithms with names, functions, and tests that another learner can read
  • CS Fundamentals + Clean Code: Apply clean-code judgment when building models, choosing abstractions, and explaining program structure
  • All Modules + Prior Learning: Use Pre-Semester tooling (command line, Git) to review, refactor, and document code changes clearly

Readiness for Mathematical Foundations (Semester 1)​

  • Algorithm implementation skills with clean, testable code
  • CS mental model providing context for mathematical concepts
  • Problem-solving approach combining systematic thinking with clean implementation
  • Technical communication through clear code and documentation