The 7 VS Code Settings I Change on Every New Machine (and Why the Defaults Slow You Down)

I established a new machine recently and measured the time it took before VS Code felt personally tailored. The process spanned approximately 15 minutes, primarily occupied by modifying the same seven configurations I consistently alter. The default settings are not subpar; they cater to initial users. However, if you are perusing this, you are not a novice, nor is your experience identical. These seven adjustments significantly impact an editor's usability, transforming it from an impediment to a seamless tool.

1. editor.fontLigatures: true The default setting is false, resulting in code like != and = being displayed as two separate characters. Enabling ligatures merges these into singular symbols, enhancing legibility on dense lines. My preferred font, Cascadia Code, inherently supports ligatures without any additional cost or compromise in readability.

2. editor.formatOnSave: true This single setting has prevented numerous disputes more effectively than any other. Upon saving a file, it automatically formats the code, managing indentation, spacing, and trailing commas. I no longer ponder formatting or submit files with sloppy spacing due to urgency. The caveat lies in the fact that the formatter only operates if your project has a designated formatter. For Python projects, Black or Ruff must be configured; otherwise, the feature remains ineffective.

3. files.autoSave: afterDelay (with files.autoSaveDelay: 1000) I previously lost work due to crashes and closed tabs. Not substantial portions, but the last minutes of my efforts, which are more disheartening than losing significant content. Auto-save mitigated this issue. The default afterDelay value is 1000 milliseconds, allowing the editor to save after one second of inactivity. Shorter intervals might disrupt your thought process, prompting formatters and linters prematurely.

4. editor.tabSize: 2 (with editor.detectIndentation: false) VS Code infers indentation from the file, often inaccurately. Opening files where half the lines use two spaces and the other half use four spaces due to the editor's inconsistent detection has happened to me. Disabling detection and setting the tab size to 2 ensures consistent indentation across all files.

For JavaScript, TypeScript, HTML, CSS, and most configuration files, two spaces are standard. However, Python files override this setting to 4, which is correct.

5. editor.minimap.enabled: false The minimap, a compact code preview on the right edge, is visually appealing but rarely utilized for navigation. Its presence consumes approximately 10% of my horizontal screen space and displays a compressed version of my code, making it difficult to read.

6. workbench.startupEditor: none By default, VS Code opens with a welcome tab upon startup. I have perused the welcome tab and do not require repeated exposure. Setting the startup editor to none allows the editor to launch directly to my last files, enabling immediate work without the need to close a tab first.

7. editor.cursorBlinking: solid (with editor.cursorSmoothCaretAnimation: on) Two settings, one principle: reduce cursor distractions. The default blinking cursor is acceptable, but a solid cursor is easier to locate when reviewing the screen after consulting documentation. The smooth caret animation, where the cursor glides instead of jumping, is initially perceived as a gimmick. However, after a day of usage, the jumpy cursor feels erratic and broken.