Code Comprehension Part 1: Hypotheses & Beacons

1. Before tracing playlist_summary.py, which evidence gives the strongest first hypothesis about the module’s purpose?

• The exact number of dictionary keys in the TRACKS sample records

  Counting keys is low-level detail. It may matter later, but it does not name the module’s responsibility.

• The test names plus the public function summarize_playlist
• The fact that the file uses an if __name__ == "__main__" guard

  The main guard tells you the file can run as a script. It does not explain the summary behavior.

• The presence of the string (favorite)

  The favorite label is one behavior, but the tests and public function reveal the broader responsibility.

2. The question is: ‘Are hidden tracks included in the final summary?’ Which region should you inspect first?

• visible_tracks() and the call to it inside summarize_playlist()
• The exact seconds value for every track in TRACKS, including the hidden song

  Durations answer the minutes question. The hidden-track question is about filtering before the summary is built.

• The string interpolation inside label_track()

  Label formatting answers how visible tracks are displayed, not whether hidden tracks are excluded.

• The final print(...) line under the main guard

  The print line only displays the result. It does not decide which tracks enter the result.

3. Which summary is strongest after reading this module?

• summarize_playlist() makes a dictionary, calls helpers, rounds minutes, and formats labels for the sample data.

  That summary overclaims from mechanics while still missing the user-visible purpose.

• The module builds a public playlist summary by hiding tracks, totaling duration, and labeling favorites.
• The module has four tracks and one of them is hidden.

  That fact is true for the sample data, but it does not generalize to what the code does.

• label_track() uses an if statement and returns a string.

  That describes one helper at the line/block level, not the module’s overall purpose.

4. Which are reliable beacons in this small Python example? (select all that apply)

• test_summary_uses_only_visible_tracks

  This test name is a specification beacon: it tells you what behavior the author expects.

• visible_tracks

  This helper name is a lexical beacon: it predicts a filter over tracks.

• public_tracks

  This local variable confirms the filtered list’s role after visible_tracks() returns.

• The local variable name label by itself

  label is useful only after you know the surrounding helper. By itself, it is too generic to carry much hypothesis weight.

5. Which is the strongest explanation of summarize_playlist() to share with a teammate?

• Names the user-visible purpose, the main plan (filter / total / label), the evidence (the tests), and one thing the reader hasn’t verified.
• Lists every line of mechanics — summarize_playlist() creates a dictionary, calls visible_tracks(), totals seconds, formats labels for the sample output.

  Pure mechanics lists what the code does but not what for. Readers can read the code themselves — your job in a summary is the layer above.

• Recites the sample data — four tracks, one hidden, one favorite.

  Summarizing the sample data describes a single execution, not the code’s behavior.

• Overgeneralizes — ‘removes hidden tracks, so no other code needs attention.’

  Overclaiming hides what you haven’t verified. Future readers can’t tell where your knowledge ends.

1. What is the best purpose hypothesis for build_event_cards()?

• It mutates EVENTS so cancelled events are permanently removed before future calls can see them each time it runs.

  The function creates a new cards list. It never writes back into EVENTS.

• It builds display-ready event card dictionaries for upcoming, non-cancelled events matching a tag.
• It prints every event to the terminal in calendar order.

  Printing happens only under the main guard. The function returns data.

• It counts the number of registered students across all events.

  Registration numbers are used only to compute spots left, not to produce a total.

2. For today=14 and tag="frontend", which answer gives the result and the evidence?

• React Snack Lab appears because it is upcoming, not cancelled, and has the frontend tag.
• Legacy Code Karaoke appears because it is full.

  Its day is before today=14, so upcoming_events() filters it out.

• Cancelled CSS Cafe appears because it has the frontend tag.

  It has a frontend tag, but cancelled is true, so upcoming_events() filters it out.

• Debugging Jam appears because it is upcoming, has open seats, and looks like a workshop card.

  It is upcoming and open, but it does not have the frontend tag.

3. Which detail can you safely ignore when answering whether cancelled events appear?

• The not event["cancelled"] condition

  That condition is the key evidence for the cancelled-event question.

• The call from build_event_cards() to upcoming_events()

  That call connects the public function to the filtering helper.

• The exact formula inside seats_left()
• The cancelled values in the sample data

  The sample data lets you verify at least one cancelled path.

4. Which small trace best verifies the hypothesis that full events are still included?

• Trace Node Night Market through upcoming_events(), matches_tag(..., "backend"), and seats_left().
• Trace every event through every helper, then compare all final cards before deciding whether full events survive.

  That is exhaustive tracing. The question only needs one event that is full but not cancelled.

• Trace only the final print(...) statement.

  The print statement displays whatever the function returns; it does not verify the route to the result.

• Trace Cancelled CSS Cafe through matches_tag(..., "frontend") and stop there.

  That event is cancelled, so it tests cancellation, not whether full events are included.

5. Which note best shows useful vary-the-input reasoning?

• If today changes to 18, React Snack Lab should disappear because the date filter runs before card creation.
• If today changes to 18, every event should appear because later dates are less restrictive and full/cancelled checks should not matter.

  A later today value is more restrictive because events must have day >= today.

• If tag changes to all, cancelled events should appear because the tag filter stops running.

  The cancelled-event filter still runs inside upcoming_events().

• If registered changes, the cancelled-event filter should change too.

  Registration affects spots left and full/open status, not cancellation.

1. Which beacon most strongly tells you that App owns state that can change over time?

• React.useState(...) calls inside App
• The <h1>Snack Vote</h1> heading inside App

  The heading helps with user-facing purpose, but it does not identify mutable state.

• The CSS class name snack-shell

  The CSS class is a presentation hook. It is weak evidence for behavior.

• The array literal named SNACKS

  SNACKS is starter data. The state beacon is where React stores the changing copy.

2. The expression snacks.filter(...).map(...) is mainly which kind of beacon?

• A structural beacon for the plan: derive a visible list, then render one element per item
• A specification beacon because the method chain proves every test passes without running assertions

  Tests and assertions are specification beacons. This expression is implementation structure.

• A useless cue because array methods never help comprehension in a React render path

  Array methods are often excellent structural beacons when the reader knows the plan they encode.

• A CSS beacon because it controls grid layout

  CSS controls layout, but .filter(...).map(...) controls data selection and rendering.

3. A reader wants to know what happens when the Vote button is clicked. Which path should they inspect?

• SnackCard’s onClick, the onVote prop, and handleVote in App
• The CSS file, because click handlers are styled via class selectors

  CSS can change appearance, but the click behavior is in JSX and state updates.

• The SNACKS starter array, because the click reads its initial values

  The starter data explains initial values, not the click interaction.

• The category selector’s <option> elements, because filters control button behavior

  The selector controls category filtering, not vote increments.

4. Which beacons are strong enough to support a first-pass prediction? (select all that apply)

• visibleSnacks suggests a filtered list of snacks.

  The name directly states the role of the derived list.

• onVote suggests a callback prop from parent to child.

  The on... prop naming convention is a common React beacon for event callbacks.

• snack-grid proves the app stores votes in localStorage for the next visit.

  A CSS class can suggest layout, but it says nothing about persistence.

• key={snack.id} suggests React is rendering a list.

  key is a React list-rendering beacon.

5. Which cue is the weakest evidence for how votes change?

• snack-grid, because it mainly names a layout hook
• onClick={() => onVote(snack.id)}, because it shows the button sends an id

  This is strong interaction evidence: the click calls a callback with the snack id.

• handleVote(id), because it names the parent-side update path

  This is strong lexical and structural evidence for the vote behavior.

• setSnacks(currentSnacks => currentSnacks.map(...)), because it shows the state update

  This is the strongest implementation evidence for how votes change.

1. Which component owns the selected topic state?

• App, because it calls React.useState("all") and passes topic plus setTopic down
• TopicFilter, because it renders the <select> element and handles the user’s change event first

  TopicFilter receives the current value and callback as props. Rendering a control does not mean owning its state.

• TaskCard, because each card displays a task topic

  TaskCard is display-only in this code. It receives one task and does not call useState.

• TASKS, because it stores every task’s topic string

  TASKS is static data, not React state.

2. If the selected topic is react, which task appears?

• Trace prop callback
• Read route tests

  That task has topic node.

• Label accumulator role

  That task has topic python.

• Map route to helper

  That task has topic node.

3. When does the Everything visible is done. status appear?

• When visible tasks exist and all of them are done
• When any task in TASKS is done, even hidden ones

  The code uses visibleTasks.every(...), so hidden tasks do not control the banner.

• Whenever the selected topic is all

  The all topic includes unfinished tasks in the sample data, so the banner does not appear there.

• Only when TaskCard decides to render it

  TaskCard renders individual task status. The overall banner is in App.

4. Which statements are good evidence-based summaries of this React code? (select all that apply)

• App owns the topic state and derives visibleTasks from static task data.

  This connects state ownership to derived data, which is the main behavior.

• TopicFilter sends selection changes upward through onTopicChange.

  This correctly follows the callback prop from child to parent.

• TaskCard mutates each task’s done value when it renders and passes the change back to App.

  TaskCard only reads task.done; it never changes the task object.

• visibleTasks.map(...) renders one card per visible task.

  This is the list-rendering plan in the JSX.

5. What plan is shared by the Python event-card sprint and this React study-queue sprint?

• Both filter a source collection, then shape items for the user.
• Both save user choices in localStorage.

  Neither example persists data across page reloads.

• Both mutate the original sample data before rendering it.

  Both examples derive new values without mutating the starter collection.

• Both use route handlers to return JSON.

  Route handlers are part of backend Node examples, not these Python and React snippets.

6. You opened App.jsx and read the components. What is the next routine move before you commit to an answer about the completion banner?

• Verify — trace one small input through the relevant conditional to confirm or refute the hypothesis.
• Refactor — clean up the JSX so the banner condition becomes more readable.

  Refactoring changes the code; comprehension is reading-only.

• Test — write a brand-new test for the banner before answering.

  Writing new tests is a separate workflow; the routine’s verify step is targeted, not additive.

• Print — log every state value to the console.

  Print-everything debugging is bottom-up exhaustive tracing — the opposite of what the routine prescribes.

1. For the tied-scores input — [('Ana','python',90), ('Ben','python',90), ('Ana','react',80)] — what does top_student_per_topic(scores) return?

• {'python': 'Ben', 'react': 'Ana'} — Ben wins the tie because the conditional uses >=, so the second 90 replaces the first.
• {'python': 'Ana', 'react': 'Ana'} — Ana wins because she appears first, and max-tracking plans use first-wins on ties.

  This is the standard max-tracking plan, but the function uses >=, not >. Ties replace the current leader instead of preserving it.

• {'python': ['Ana', 'Ben'], 'react': 'Ana'} — both Ana and Ben are returned because they tied.

  The function returns dict[str, str], not dict[str, list[str]]. The line leaders[topic] = (student, score) only holds one student at a time.

• {'python': 'Ana, Ben', 'react': 'Ana'} — names combined into a single string.

  Nothing in the code concatenates names.

2. Which specific expression makes Ben win the tie over Ana?

• if topic not in leaders or score >= leaders[topic][1]: — the >= (not >) allows the second occurrence with the same score to overwrite the first.
• leaders[topic] = (student, score) — assignment alone causes replacement.

  Assignment causes replacement, but only if the guard allows it. The guard is the operator.

• return {topic: name for topic, (name, _) in leaders.items()} — the dict comprehension shuffles the order.

  Dict comprehensions preserve insertion order in modern Python; they don’t shuffle.

• for student, topic, score in scores: — unpacking changes who appears first.

  Tuple unpacking is mechanical. It doesn’t reorder.

3. What was the recovery move that exposed the gap between the familiar plan and this implementation?

• Trace one carefully chosen input (a tie) through the conditional, paying attention to operators.
• Re-read the entire function from the top down, three times.

  Re-reading without a specific question won’t reveal the operator distinction. The point is targeted attention.

• Run the test suite and inspect every passing test.

  The included tests don’t pin down tie behavior (one asserts only that ‘python’ maps to Ana or Ben). Running them won’t tell you what happens with ties.

• Search the codebase for other uses of top_student_per_topic.

  External usages don’t explain internal semantics.

4. Which observations about the existing tests are accurate? (select all that apply)

• test_ties_resolved_by_appearance_order() is named for a specific tie semantics but asserts only that the result is one of Ana or Ben — leaving the tie behavior unpinned.

  Yes — the test name says ‘appearance order’ but the assertion only checks that the key exists with one of two values. The test is underspecified.

• The two non-tie tests would still pass even if the operator were changed from >= to >.

  Yes — the no-tie tests don’t exercise the >=/> distinction at all.

• Running the tests would tell you definitively whether ties resolve to first-wins or last-wins.

  Running them gives only one outcome; you can’t compare against the alternative without changing the code.

• The test suite covers the tie boundary case tightly.

  The name suggests tightness, but the assertion is loose. The test passes for both >= and >.

5. Which single-character change to the function would make the standard ‘max-tracking first-wins’ plan true?

• Change >= to > in the conditional.
• Change (student, score) to (score, student) in the tuple.

  Tuple order would change how tuples compare — but the code compares leaders[topic][1] (the score), not the full tuple. Reordering does nothing here.

• Change not in to in in the guard.

  Inverting the guard would assign only when the topic is already present — breaking the function entirely on first occurrence.

• Change .items() to .keys() in the comprehension.

  Switching to .keys() would break the unpacking inside the comprehension.

1. What role does topic_minutes play in summarize_minutes()?

• It is an organizer and accumulator: it groups minutes by topic and updates each total.
• It is a flag that records whether any topic passed the threshold.

  The threshold check happens later in recommend_badges(). This dictionary stores grouped totals.

• It is a stepper that moves through the activity log one entry at a time and remembers the current row.

  entry is the loop stepper. topic_minutes persists across loop iterations.

• It is a display string for one badge.

  Display strings are appended to badges; topic_minutes stores numeric totals.

2. Which variables are the strongest beacons for the best-so-far plan?

• best_topic and best_minutes
• entries and entry

  Those names support the loop structure, but they do not identify the current winner.

• badges and name

  badges gathers output strings; it is not choosing the strongest topic.

• minimum_minutes and the current topic

  minimum_minutes is a threshold, and topic is a local item from iteration or return unpacking.

3. What is the best purpose-level summary of recommend_badges()?

• It turns an activity log into badge labels by aggregating minutes per topic and thresholding.
• It prints every activity in sorted order.

  Printing happens only under the main guard. The function returns badge labels.

• It drops React entries because one React activity has zero minutes, treating the topic as invalid.

  The zero-minute React entry is ignored, but other React minutes still count.

• It finds the first topic in the log and returns only that topic.

  The code aggregates all topics and then evaluates each total.

4. Which trace best verifies that zero-minute entries are ignored?

• Trace the React zero-minute entry into summarize_minutes() and stop at continue.
• Trace every entry through strongest_topic() and infer skipped values from the winner.

  The zero-minute behavior is decided before strongest_topic() runs.

• Trace the badges.append(...) line for every topic.

  Badge appending happens after totals are already computed.

• Trace only the final print(...) statement.

  The print statement displays the result; it does not prove why one entry was skipped.

5. Which statements correctly connect variable roles to programming plans? (select all that apply)

• topic_minutes supports an aggregation plan.

  The dictionary stores cumulative totals by topic.

• best_topic and best_minutes support a max-tracking plan.

  Those variables remember the current strongest topic and its score.

• badges supports a gather-output plan.

  The list grows with the final display labels.

• entry proves the code is doing React state management because each item looks like a component prop.

  entry is a generic loop variable in Python; it does not imply React behavior.

6. The expression topic_minutes[topic] = topic_minutes.get(topic, 0) + entry["minutes"] is mainly which kind of beacon?

• Structural — a recognizable accumulator/aggregator shape that triggers a stored programming plan.
• Framework — a React- or Node-specific API call.

  No React or Node imports here; this is plain Python.

• Specification — a test assertion that pins down behavior.

  Assertions live in test files, not in production aggregation code.

• Aesthetic — code that signals professional style.

  Aesthetic is not a behavior beacon.

1. What is the strongest purpose hypothesis for build_habit_report()?

• It builds a summary of useful check-ins with totals and the longest streak.
• It unskips and rewrites the original check-in list before producing the report.

  The function filters data into a new list; it does not mutate the original check-ins.

• It prints every check-in in chronological order.

  Printing happens only in the script guard. The function returns a dictionary.

• It renders a React list of habits.

  This is Python data-processing code, not React JSX.

2. Which helper is central for deciding whether skipped check-ins count?

• useful_checkins()
• minutes_by_skill()

  This helper aggregates after the skipped and zero-minute entries are removed.

• longest_streak()

  This helper works on the already-filtered check-ins.

• sum(totals.values())

  The sum happens after filtering and grouping.

3. If skill="python", which check-ins can affect total_minutes?

• Only useful Python check-ins: days 1, 2, and 6
• Every Python check-in, including the skipped zero-minute day

  The skipped zero-minute check-in is removed by useful_checkins() before skill filtering.

• Every useful check-in across Python, React, and Node

  The skill filter removes React and Node when skill is not all.

• Only the longest streak days

  Streaks are computed separately; totals come from minutes_by_skill().

4. Which pair best shows the same aggregation purpose through different structures?

• minutes_by_skill() and sum(totals.values()): both collapse useful minutes into summary data.
• useful_checkins() and the script print(...): both decide which records are skipped.

  useful_checkins() decides eligibility, while print(...) only displays the returned report.

• longest_streak() and the type declarations: both format the final output labels.

  longest_streak() computes a run; type declarations describe shapes for readers and tools.

• CHECKINS and HabitReport: both compute the current longest run.

  CHECKINS is sample data and HabitReport is a shape annotation. Neither computes the streak.

5. Which detail can you ignore if the only question is whether skipped check-ins contribute to totals?

• The exact streak reset logic in longest_streak()
• The predicate inside useful_checkins()

  That predicate directly decides whether skipped entries are removed.

• The call to minutes_by_skill(useful) that computes totals from the filtered check-ins

  Totals are computed from the filtered list, so this call helps connect filtering to output.

• The if skill != "all" branch

  The skill branch can further narrow which useful check-ins contribute.

6. Which plan labels fit this Python example? (select all that apply)

• Filter invalid or irrelevant records

  useful_checkins() and the skill filter remove records before summarizing.

• Aggregate minutes by key

  minutes_by_skill() groups totals by skill.

• Track a longest consecutive run

  longest_streak() tracks a best-so-far value across sorted days.

• Send an HTTP response from a route handler

  There is no request or response object in this Python example.

7. In longest_streak(), what role does previous_day play?

• Most-recent holder — it remembers the last value seen so the next iteration can compare to it.
• Accumulator — it sums the total streak length across the loop.

  The accumulator is current (current run length); previous_day is what gets compared to.

• Stepper — it advances through days one element at a time.

  The stepper is day — the loop variable from for day in days.

• Flag — it is a boolean recording whether a streak has happened.

  It is int | None, not a boolean.

1. For audience="students" on day 9, why does Faculty Mixer not appear in the feed?

• audience_can_see() rejects it because its audience is faculty, not students or all.
• pinned_label() hides it because pinned announcements are formatted separately before eligibility is decided.

  This is the misleading beacon: pinned is real, but pinned_label() runs only after an announcement is eligible. It changes the label, not visibility.

• is_active() rejects it because day 9 is outside its date range.

  Day 9 is inside the Faculty Mixer date range, so the date hypothesis does not survive tracing.

• channel rejects it because event announcements are never shown.

  The code never filters out the events channel.

2. Which line of reasoning best tests the pinned-announcement hypothesis?

• Check whether pinned is read before or after the eligibility filters.
• Assume pinned announcements must always be visible because that is what pinned usually means.

  This answer follows the misleading beacon without testing it. A strong reader asks where pinned is used in the flow before trusting the name.

• Count how many announcements are in ANNOUNCEMENTS.

  Counting records does not explain which records enter the feed.

• Start from card_for() because it builds the final dictionaries.

  card_for() formats announcements that already survived eligibility; it is too late for the visibility question.

3. What does the announcement contrast set reveal about pinned?

• pinned changes order and labels after eligibility, not visibility.
• pinned always overrides audience, date, and archive filters.

  The hidden pinned examples show that eligibility still runs first.

• pinned is ignored everywhere because Faculty Mixer is hidden.

  Study Jam is not pinned but still appears, while pinned announcements can be hidden for other reasons.

• pinned only matters for announcements on the alerts channel.

  The code does not special-case the alerts channel for pinned behavior.

4. Which code regions are central evidence for the Faculty Mixer visibility question? (select all that apply)

• build_feed()

  build_feed() shows the order: eligibility first, sorting/formatting second.

• audience_can_see()

  audience_can_see() is the helper that rejects faculty-only announcements for the student feed.

• is_active()

  is_active() must be checked because date and archive status are also eligibility filters.

• pinned_label()

  This is the misleading beacon for this question. pinned_label() is relevant to display text, but it cannot explain why an item never became eligible.

• The channel field value

  The field looks domain-relevant, but no predicate reads channel in this example.

5. Which final explanation best fits the evidence?

• Faculty Mixer is pinned, but pinned status only changes ordering and labels after eligibility; the student audience filter rejects it.
• Faculty Mixer is missing because pinned announcements are hidden by default before audience rules run.

  This keeps following the misleading beacon. The code uses pinned status for sort order and labels, not for hiding.

• Faculty Mixer is missing because event announcements are archived automatically.

  The archive decision is explicit in the data; Faculty Mixer has archived: False.

• Faculty Mixer is missing because card_for() deletes announcements with faculty in the title after label formatting, so the final card list skips it.

  card_for() receives already-eligible announcements and never checks the title for faculty text.

6. Your final explanation should follow the EiPE frame. What does the trailing L stand for?

• Limit — what you have not verified yet (input ranges, edge cases, related branches).
• Loop — the iteration shape used by the function.

  Iteration shape is part of mechanism, not the boundary of the claim.

• Logging — what the function writes to stdout.

  Logging is rarely on the comprehension path here.

• Layout — how the code is visually formatted.

  Visual formatting is a presentation concern, not an explanation frame.