How to remove console.log statements from a project in VS Code

Short answer: a regex Replace All in VS Code's search works for simple one-line calls, but it also deletes code that shares the line and misses multi-line calls. For a safe cleanup, use a tool that understands comments and strings and only removes statements that stand alone, then add an ESLint rule so new ones are caught in review. DevSnip Pro's Clean Debug Logs does the first part for JavaScript, TypeScript, Python, Java, Kotlin, C#, Dart and Swift.

Debug logging is the fastest way to see what a value really is. The trouble is the cleanup: a forgotten console.log leaks data into the browser console, a stray print fills production logs, and hunting them down by hand before every commit is tedious.

Option 1: regex search and replace (quick, with caveats)

Open search across files with Ctrl/Cmd+Shift+H, turn on regular expressions with the .* button, and search for:

^[ \t]*console\.log\([^;\n]*\);?[ \t]*\n

Leave Replace empty, review the matches in the sidebar, and replace. The pattern only matches a call that fills its whole line and stops at the first semicolon, so it can't delete code that follows a log on the same line. The cost is that logs containing a ; (for example inside a string) are skipped.

It still has limits:

• Multi-line calls such as console.log(\n user,\n order\n) don't match, so they stay behind.
• Comments and strings match too: a line in a template literal or a commented-out example gets deleted.
• Empty blocks can be left behind. In Python, removing the only print in an if body is a syntax error.
• It only covers one language and one function name per search.

Use the files to include field (for example src/**) to keep it away from node_modules, generated files and vendored code.

Option 2: Clean Debug Logs in DevSnip Pro

Run DevSnip Pro: Clean Debug Logs from the Command Palette (Ctrl/Cmd+Shift+P). It scans the workspace and lists what it found before changing anything:

• console.log, print, pprint, breakpoint(), System.out.println, Log.d, Console.WriteLine, Debug.WriteLine, debugPrint, NSLog, dump and similar calls, including in <script> blocks of HTML, Vue, Svelte and PHP files.
• Calls inside comments and strings are ignored.
• Only statements that stand alone on their lines are removed. A call that shares a line, continues an expression or is the body of an if without braces is listed for review instead of being deleted.
• The code stays valid: a Python block left empty gets pass, and a Swift or Dart case left empty gets break. Line endings are kept.

It asks before deleting; the setting devsnip.consoleLogCleanup.confirmBeforeDelete controls that. For just the file you're in, run Remove Debug Logs in This File, and Undo reverts it if you change your mind.

Your real logging is safe: calls through your project's logger (logger.info, _logger.LogInformation and so on) are not touched unless DevSnip Pro wrote them itself.

Write debug logs that are easy to find again

Half of the cleanup problem is logs that look like real code. Insert Debug Log (Ctrl+Alt+Shift+L) logs the variable under the cursor with a [file:line] label, in the right place: after the assignment, at the top of a function for a parameter, at the top of a loop for its variable.

const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
console.log('[cart.ts:14] total:', total);

If the file already has a logger, it uses that instead of print or console.log:

total = sum(item.price * item.qty for item in items)
logger.debug("[orders.py:12] total=%r", total)

Because every inserted log carries its label, Clean Debug Logs recognises and removes it later, even when it goes through a project logger.

Option 3: stop new ones at review time

Cleanup tools fix today's logs. A lint rule stops tomorrow's. With ESLint's flat config:

// eslint.config.js
export default [
  {
    rules: {
      'no-console': ['warn', { allow: ['warn', 'error'] }],
    },
  },
];

This flags console.log while allowing console.warn and console.error, which are usually intentional. Run ESLint in CI so a stray log fails the check instead of reaching production. Python projects can do the same with Ruff's T20 rules (flake8-print), which flag print and pprint.

What about stripping logs at build time?

Bundlers and minifiers can drop console calls from production builds, for example esbuild's drop option or Terser's drop_console. That keeps them out of the shipped bundle, but they stay in your source and in code review. It works best as a safety net alongside a cleanup and a lint rule, not instead of them.

A routine that works

1. Debug with labelled logs (Insert Debug Log), so they're easy to spot.
2. Before committing, run Clean Debug Logs, read the list, and review anything it flagged instead of removing.
3. Let ESLint or Ruff catch anything that slipped through in CI.