View source for Beyond Print Statements: Breakpoint Debugging

[[Category:Beginner's_Guide_Implementation]]

{{ImplementationSidebar}}

This guide introduces breakpoint debugging, a crucial skill for writing reliable and efficient code in statistical research. When writing complex simulations, custom likelihood functions, or data cleaning pipelines, your code will inevitably fail or produce unexpected results. How you track down these errors determines whether a bug takes five minutes or five hours to fix. 

<div style="background-color: #fff3cd; border-left: 5px solid #ffc107; padding: 15px; margin-bottom: 20px; margin-top: 15px; overflow: hidden;">
'''Important: Stop Guessing, Start Inspecting'''<br>
As your scripts grow from simple homework assignments to multi-file research pipelines, rudimentary debugging methods will waste massive amounts of your time. Investing an hour now to learn your IDE's visual debugger will save you weeks of frustration over the course of your PhD.
</div>

== The Old Way: Inefficient Debugging Modes ==
Many beginners rely on two intuitive but highly inefficient methods to find bugs. While these can work for short, simple scripts, they quickly break down in complex statistical programming.

'''1. Inline Print Statements ("printf debugging")'''
This involves inserting <code>print()</code>, <code>cat()</code>, or <code>disp()</code> statements throughout your code to check the values of variables or to confirm a specific block of code was reached.
* '''The Problem:''' It requires constantly editing your source code, saving, and re-running the entire script. In statistical research, where running a script might involve fitting an MCMC model that takes 20 minutes, restarting the process just to see a variable's state is an immense waste of time. Furthermore, it's easy to accidentally commit print statements to your final codebase.

'''2. Manual Interactive Querying'''
Common in interpreted languages like R and Python, this method involves running your script line-by-line in the console (or running chunks in a Jupyter notebook) until an error occurs, and then manually querying the global environment to see what went wrong.
* '''The Problem:''' This method fails completely when bugs are buried inside nested functions, apply-family functions, or loops. The global environment won't show you the local variables inside a failing function's scope. This forces you to manually copy-paste function arguments to recreate the local state—a tedious and error-prone process.

== The Better Way: Breakpoint Debugging ==
Breakpoint debugging allows you to set specific markers (breakpoints) in your code. When the interpreter reaches a breakpoint, it completely pauses execution. You can then interact with the program exactly as it exists at that specific millisecond.

{| style="width: 100%; border-collapse: collapse; margin-bottom: 10px;"
|-
! style="background-color: #d4edda; color: #155724; padding: 10px; text-align: left;" | Advantages of Breakpoint Debugging
|- style="vertical-align: top; background-color: #f8f9fa;"
| style="padding: 15px;" |
* '''Local Scope Inspection:''' When execution pauses inside a function, you can inspect the exact local variables and arguments without polluting your global environment or altering your code.
* '''Step-Through Execution:''' You can execute your paused code line-by-line (stepping over or stepping into functions) to watch exactly how variables and datasets mutate in real-time.
* '''On-the-Fly Evaluation:''' While paused, you can use the interactive console to test fixes. You can run test equations on the current state of variables to see if your proposed fix works before ever editing the source file.
* '''Conditional Pausing:''' Advanced tools allow you to set conditional breakpoints (e.g., "only pause execution if the matrix determinant goes exactly to 0"), which is invaluable for debugging stochastic loops.
* '''No Code Modification:''' Breakpoints are managed by your IDE. You don't have to add or delete "junk" code to debug, keeping your scripts clean.
|}

== Setup Guides by Environment ==
Most modern statistical programming is done in an Integrated Development Environment (IDE) that fully supports visual breakpoint debugging. Choose your primary environment below to learn how to set it up:

<div style="background-color: #f8f9fa; border-left: 4px solid #75AADB; padding: 15px; margin-bottom: 10px;">
'''RStudio (R)'''<br>
RStudio has one of the most intuitive visual debuggers built-in. You simply click to the left of the line number to set a red breakpoint circle. When the script hits that line, your console turns into a <code>Browse[1]></code> prompt, and the Environment pane shows the local function scope.<br><br>
🔗 '''[https://support.posit.co/hc/en-us/articles/205612627-Debugging-with-the-RStudio-IDE Official Guide: Debugging with the RStudio IDE]'''
</div>

<div style="background-color: #f8f9fa; border-left: 4px solid #005A9C; padding: 15px; margin-bottom: 10px;">
'''VS Code (Python / R / Julia)'''<br>
VS Code requires a bit more configuration via the "Run and Debug" tab, but it provides a universally powerful debugging interface for almost any language you will use in the department. <br><br>
🔗 '''[https://code.visualstudio.com/docs/editor/debugging Official Guide: Debugging in VS Code]'''
<br><br>
🔗 '''[https://code.visualstudio.com/docs/python/debugging Debugging Python in VS Code]'''
</div>

<div style="background-color: #f8f9fa; border-left: 4px solid #F37726; padding: 15px; margin-bottom: 10px;">
'''Jupyter Notebooks (Python)'''<br>
While Jupyter historically encouraged interactive querying, modern JupyterLab and Jupyter Notebook v7+ feature a built-in visual debugger. By clicking the "bug" icon, you can enable a sidebar to view call stacks and set breakpoints directly in your notebook cells.<br><br>
🔗 '''[https://jupyterlab.readthedocs.io/en/stable/user/debugger.html Official Guide: The JupyterLab Debugger]'''
</div>