HiveCore Dev logo hivecore.dev

settings.json: The Power-User Configuration

// VS Code · HiveCore Dev · updated 2026-05-09
// what's in here
  1. The short version
  2. Working example
  3. Why this pattern
  4. A common variant
  5. Trade-offs to watch
  6. A more involved example
  7. When to skip it
  8. FAQ

TL;DR: GUI settings are for casuals. settings.json is where serious customization lives. Here's the 30-line baseline.

The short version

GUI settings are for casuals. settings.json is where serious customization lives. Here's the 30-line baseline.

This guide covers the mental model, the patterns that pay off, and the trade-offs that decide whether a technique fits your code.

Working example

Here's a minimal example you can run as-is. Drop it in a fresh file, run it, and trace through it once before reading the rest.

{
  "editor.fontFamily": "JetBrains Mono, Menlo, monospace",
  "editor.fontSize": 14,
  "editor.formatOnSave": true,
  "editor.tabSize": 2,
  "editor.bracketPairColorization.enabled": true,
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,
  "git.autofetch": true,
  "workbench.startupEditor": "none",
  "[python]": {
    "editor.tabSize": 4,
    "editor.defaultFormatter": "charliermarsh.ruff"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

Why this pattern

The shape above shows up in real VS Code codebases because it satisfies three constraints at once: it stays type-safe, it composes with the rest of the language's idioms, and it leaves a clear trail for the next developer (which, in six months, is you).

When you write the same pattern three times in a project, extract it. When you write it three times across projects, extract it into a shared library.

// recommended — github-copilot GitHub Copilot — the VS Code extension with the largest gap to alternatives

A common variant

The same idea adapted for a different shape. Notice how the structure stays the same — only the specifics change.

{
  "recommendations": [
    "charliermarsh.ruff",
    "ms-python.python",
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "rust-lang.rust-analyzer",
    "golang.go",
    "tamasfe.even-better-toml",
    "redhat.vscode-yaml",
    "github.copilot",
    "eamodio.gitlens"
  ]
}

Trade-offs to watch

Every pattern has a failure mode. The most common one here is over-application: developers who learn a technique apply it everywhere, including places where simpler code would have been clearer.

Rule of thumb: if the abstraction takes more lines to describe than it saves, the abstraction is wrong.

A more involved example

Once the basic pattern is clear, here's how it composes with surrounding code. Read this one slowly.

{
  "Console log labeled": {
    "scope": "javascript,typescript,typescriptreact",
    "prefix": "cll",
    "body": [
      "console.log('${1:label}:', $0);"
    ],
    "description": "Labeled console.log"
  }
}

When to skip it

If the surrounding code is already simple, don't reach for VS Code-specific cleverness. Boring code is a feature. Save the patterns for places where they actually pay off — usually at module boundaries, in shared libraries, or where the alternative would be 50 lines of repetition.

// recommended — cursor Cursor — VS Code fork with first-class AI editing

FAQ

Is this still current in 2026?

Yes. The patterns shown here are stable across recent versions and reflect what working teams actually ship.

Where do I learn more?

Read the official docs first, then the source of a project you respect. Tutorials get you to the door; source code gets you inside.

Does this work for production?

The exact code in this article is illustrative — copy the shape, adapt the specifics. For production, add logging, add tests, handle the failure modes called out above.

Related reading