How to Set Breakpoints and Debug in VS Code (F9 and F5)

F9 toggles a breakpoint on whichever line the cursor is currently on, marked by a red dot that appears in the gutter to the left of the line numbers. When a debug session's execution reaches a line with an active breakpoint, it pauses there automatically, letting you inspect variables, the call stack, and the console before deciding how to proceed. **Setting breakpoints without starting a debug session**: you can place breakpoints with F9 at any time, even before a debugger is running — they're stored as part of your editor state and take effect the next time you start a session with F5, so it's common to set several breakpoints across multiple files before kicking off a debug run, rather than setting them reactively after execution has already started. **Conditional breakpoints**: right-clicking an existing breakpoint's red dot offers the option to add a condition (like 'only pause when i > 10'), which has no default keyboard shortcut but is worth knowing exists for debugging issues that only manifest after many loop iterations, where pausing on every single pass would be impractically slow to step through manually. **Starting and resuming with F5**: pressing F5 with no debug session active starts one using the configuration selected in the Run and Debug panel (or prompts you to create one if none exists in .vscode/launch.json). Once paused at a breakpoint, pressing F5 again resumes execution rather than starting a new session — the same key means different things depending on whether a session is currently running and paused. **Stepping through code once paused**: F10 (Step Over) runs the current line in one go and lands on the next line, skipping past any functions it calls rather than descending into them; F11 (Step Into) instead follows execution into a called function so you can trace what happens inside it; Shift+F11 (Step Out) finishes off the current function automatically and drops you back at the line that called it. **A common first-time gotcha**: if F5 does nothing or immediately throws an error about a missing configuration, it usually means no launch.json exists yet for the project, or the existing configuration doesn't match your project's actual entry point or runtime — the Run and Debug panel's 'create a launch.json file' link generates a reasonable starting template for most common project types. **Related shortcuts**: F10 and F11 for stepping once paused, and Shift+F5 to stop a debug session entirely rather than just pausing or resuming it. **Mistake to avoid**: setting a breakpoint on a line that never actually executes (inside a conditional branch that isn't taken, or on a comment/blank line where VS Code silently moves the breakpoint to the nearest executable line) leads to confusion when a debug session runs to completion without ever pausing — if a breakpoint you expect to hit doesn't, first confirm the exact line actually executes in your current code path before assuming the debugger itself is misconfigured. **Logpoints as a breakpoint variant**: right-clicking in the gutter and choosing 'Add Logpoint' instead of a regular breakpoint creates a special marker that logs a message to the console without pausing execution at all, which is often more useful than a full breakpoint for tracking a value across many loop iterations where pausing every single time would be impractical to click through manually. **Breakpoints persist across VS Code sessions**: closing VS Code entirely, or even rebooting the machine, leaves previously set breakpoints tied to the workspace intact, so picking a multi-day bug back up doesn't mean re-clicking every breakpoint into place from scratch — they remain until manually removed or until the exact line they're attached to is deleted from the file.