Quiz: Debugging

Week 3 · Advanced Statistical Programming using R

Recap: Functions

Q1

Which function name best follows the naming guidance from the lecture?

  1. my_function(data)
  2. f(x)
  3. summarise_by_species(df)
  4. test2(penguins)

Answer: 3) A function’s name should describe what it does, not what it is.

Q2

What is the core idea of the Outside-In approach?

  1. Write the function body first, then figure out a name and arguments afterwards
  2. Always copy & paste working code into a function block
  3. Write the call before you write the body
  4. Write the longest possible function first, then shrink it down

Answer: 3) Outside-In starts from the interface: output <- what_am_i_trying_to_do(information_piece, another_piece) first. Ask the three questions from lecture 2 about Task, Inputs & Output.

Errors & Asking for Help

Q3

R distinguishes between three types of conditions. Which set is correct?

  1. Error, Bug, Crash
  2. Bug, Overflow, Terminal
  3. Syntax, Runtime, Logic
  4. Error, Warning, Message

Answer: 4) An Error stops execution, a Warning lets the code finish but signals possible issues, and a Message is informational only.

Q4

You run the following code and get an error:

library(tidyr)
mtcars |> filter(cyl == 4)
#> Error in filter(mtcars, cyl == 4) : could not find function "filter"

What is the most likely cause?

  1. mtcars does not contain the column cyl
  2. The package providing filter() (here dplyr) has not been loaded
  3. The pipe operator |> is not supported in base R
  4. R needs to be reinstalled

Answer: 2) filter() is a dplyr function, but only tidyr was loaded. Add library(dplyr). “Could not find function” almost always means a missing library() call.

Q5

You want to ask for help to fix a bug. Which of the following is NOT a good principle for a Minimal Reproducible Example (MRE)?

  1. Use built-in datasets like mtcars or create small example data
  2. Include any library() calls needed to run the code
  3. Paste your full script so the helper has full context
  4. Strip out code unrelated to the actual problem

Answer: 3) “Minimal” means the fewest lines that still reproduce the problem.

Q6

What does dput() do, and why is it useful when sharing a problem online?

  1. Deletes a variable to free memory
  2. Converts an R object into code that can be pasted and run to recreate the object exactly
  3. Prints debug information to a log file
  4. Automatically formats code with consistent indentation

Answer: 2) Use dput() to convert data to code if you must share real data.

Debugging Tools

Q7

What does traceback() (or rlang::last_trace()) show you after an error?

  1. A suggested fix for the error
  2. The sequence of function calls that led up to the error (the call stack)
  3. The line number of the error in your source file
  4. A link to relevant Stack Overflow posts

Answer: 2) Traceback shows the call sequence leading up to an error, which is useful for understanding where the error occurred in our nested code.

Q8

You inserted browser() in your function. R pauses and shows Browse[1]>. You type n and press Enter. What happens?

  1. Quits the debugger
  2. Steps into the next function call
  3. Prints the names of all variables
  4. Executes the next line and pauses again

Answer: 4) n = next: run the next line, then pause again. Other key commands: s step into, f finish, c continue, Q quit.

Q9

Which statement about debugonce(fn) or debug(fn) is correct?

  1. debugonce() runs faster than debug(fn)
  2. debug() only works on functions you wrote yourself
  3. debug() triggers on every call until undebug() is run
  4. debugonce() can automatically fix simple bugs

Answer: 3) debug(fn) keeps pausing on every invocation until you call undebug(fn). debugonce(fn) triggers exactly once and auto-removes.

Working with LLMs

Q10

Your favourite LLM wrote you some R functions. Which actions follow the guidelines from the lecture? (multiple correct answers)

  1. Run the code on a small input where you know the correct answer and check the output
  2. Check the logic based on what you know about the task
  3. If the code ran without errors, it must be correct. Commit + Push and done
  4. Re-run the same prompt and compare. We want reasonably stable output

Answer: 1, 2 & 4) Exact checks (1) verify on known input, judgement checks (2) does the reasoning make sense?, stability checks (4) re-run for stochastic output. Answer 3 is wrong, because code that runs without errors can still produce silent failures.