Settings to Make VSCode More Efficient – From a Front-End Development Perspective

☝🏻I plan to create a video tutorial later because some settings' effects require demonstration to show the differences, and I'm too lazy to make animated GIFs for the blog.

Preface

When I first started learning front-end development, VSCode didn’t exist yet—I was using WebStorm (pirated version as a student back then). The out-of-the-box experience was incredibly satisfying. Later, due to the declining performance of my office computer, WebStorm’s persistent lag issues with 4K and multi-monitor setups, influence from colleagues, and the final blow being “configuration sync,” I eventually switched to VSCode.

After adapting to the absence of a dedicated floating search box (an epic-level disconnect), I quickly figured out configurations that work well for me. Below, I’ll detail them. If anyone thinks their setup is better, feel free to leave a comment with reasons and screenshots.

📖I won't cover default settings much (unless they're exceptionally good), focusing instead on my modifications. Most configurations in VSCode can be tweaked—even settings like "whether to show the cursor line in the minimap area"—which is fantastic.

Style

Theme/Font

Theme: One Dark Pro:

marketplace.visualstudio.com https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme

Font: Fira Code:

GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures Free monospaced font with programming ligatures. Contribute to tonsky/FiraCode development by creating an account on GitHub. https://github.com/tonsky/FiraCode?tab=readme-ov-file#download--install

Fira Code is the officially recommended font, used internally as well.

Fira Code’s variant support for certain symbols is visually pleasing, such as === and <= (some require manual activation of character sets and variants):

Many dislike Fira Code’s default & symbol, but this can be disabled via configuration. Refer to its GitHub documentation for details. My setting:

1
2
3
4
5

{
  "workbench.colorTheme": "One Dark Pro",
  "editor.fontFamily": "'Fira Code', Monaco, 'Courier New', monospace",
  "editor.fontLigatures": "'ss01', 'ss02' off, 'ss03', 'ss04', 'ss05', 'ss07', 'cv29', 'cv28', 'cv13'"
}

Additionally, line height is 1.4, and font size is 13.

Editor

The most crucial part is editor settings—good configurations boost coding efficiency. Let’s break it down.

Render Whitespace Characters

I use the default “selection” setting: whitespace characters (like spaces) only appear when selected, otherwise hidden to avoid visual clutter. boundary’s setting forces them to always show, which looks messy:

Auto-Pairing/Deleting Brackets

These settings handle bracket pairing. For example, typing an opening bracket like ({[ automatically adds a closing )}]. The deletion logic works similarly. By default, pairing occurs during both insertion and deletion.

Bracket Coloring (Pool)

The first setting adds colors to brackets (instead of plain white). The second assigns each bracket type its own color scheme (though duplicates may occur—my understanding is that coloring follows bracket type order rather than display sequence).

Rectangular Selection

By default, vertical selection from top to bottom highlights entire lines if spanning line starts/ends:

Enabling this turns selection into a rectangular area (based on mouse position, not code structure). Useful for editing similarly indented lines, like JSON keys:

Side note: Holding Opt during terminal selection achieves the same effect.

Copy with Syntax Highlighting

Some rich-text editors don’t handle this well—copying code from VSCode might carry over colors unintentionally. This setting ensures copied content is plain.

Drag-and-Drop

In years of coding, I’ve rarely used drag-and-drop to move code blocks, so I recommend disabling it. The second setting: holding Shift while dragging media files into VSCode only shows filenames; releasing without Shift opens the files—a handy fallback (enabled by default).

Copy Current Line on Empty Selection

If nothing is selected (just a cursor), copying grabs the entire current line—simpler workflow (enabled by default).

Auto-Folding

Code folding is definitely necessary. Highlighting the folded range is also needed (it will follow the mouse hover effect with line-by-line highlighting of the current line), otherwise, it’s unclear whether the current line is folded. The last feature, auto-folding the import section, seems unnecessary to me.

For folding, I personally prefer it to always be visible because this feature is used so frequently. I often need to hover over the area to see which lines are folded before clicking to unfold them, which is inefficient. I like to see at a glance where the folds are, so I set it to “always”:

Bracket/Indentation Guides

As shown in the image below, though I haven’t figured out what “indentation guides” are—I’ll enable them for now.

Hover Tooltip Position

Generally, we read code from top to bottom. With this setting, hovering over code makes the tooltip appear above, blocking the content. You then have to move the mouse to dismiss it and hover again to see it. I recommend disabling this.

Hover Tooltip Delay

Moving the mouse away usually means you don’t want it to display anymore, so set it directly to 0.

Mouse Wheel Font Scaling

Frequently triggered accidentally—turn it off.

Editor Top Padding

I set it to 2. Bottom padding isn’t necessary.

Scrollbars

Horizontal scrollbar width: 6; vertical: 25 (default is 12 horizontal, 14 vertical):

Personally, I dislike scrolling beyond the content range, as it causes scrollbars to appear even when the content fits entirely on one screen. So, I disable “Scroll Beyond Last Line.”

Here’s why I increased the vertical scrollbar width to 20: that area isn’t just for scrolling—it also displays three types of information:

1. Bright yellow on the right side of the scrollbar indicates editor warnings.
2. Dark yellow blocks in the middle represent matched search terms (including global and editor searches). These blocks can also be gray (for cursor-selected content and similar matches) or light pink (for declarations of the selected content).
3. A blue line spanning the entire scrollbar row marks the cursor’s current line.
4. Green sections on the left side of the scrollbar show code changes. If Git is enabled, these may appear as light yellow for modified sections.

Given the richness of this information display, a wider scrollbar is justified.

Smooth Scrolling

Highly recommended. It lets you track how many lines you’ve scrolled instead of abruptly jumping to a new position and losing your place.

Scroll Sticky Headers

When scrolling, you might need to check content outside the current screen’s scope—enable this option. However, horizontal scrolling can move sticky functions out of view. I prefer to keep them fixed, so I disable the last option.

Cursor

The first setting enables a fade-in/fade-out effect for cursor blinking. The second adds an animation when clicking different positions, showing the cursor’s movement from its previous location. This provides more context about where the new edit position is relative to the last one.

Find Widget

Recommend disabling this. During searches, if left on, it creates unnecessary space at the file’s top, causing the editor to jump when closing the search box—annoying.

Enabling this might obscure editor content, though it’s usually just import sections or blank lines at the top, so it’s tolerable.

Auto-Populate Search Widget

Recommend turning this off. I often search, select something, then search again (for non-selected content). The editor “helpfully” auto-fills the search box with my selection, erasing my previous search—frustrating.

Minimap

I always keep the minimap on the editor’s right side visible. It helps me track my current position in the file and relative to functions/components. I prefer the minimap to stay static and only render color blocks, not every line.

Suggestions

Recommend keeping this off (default). It might conflict with Copilot suggestions. Here’s a Copilot suggestion:

And here’s a preview suggestion:

This option defaults to “first,” meaning it always uses the default first suggestion. However, I often encounter the issue that when typing wid in CSS, I naturally expect width, but it suggests widow, which I never use. Yet, it consistently ranks first, forcing me to toggle with arrow keys each time. Therefore, I suggest changing this to “recently used,” similar to the “dynamic frequency adjustment” in input methods:

Workspace

Command Prompt Box

Sometimes, I frequently repeat a command, so opening this command history list is very useful. Additionally, retaining input content is helpful, such as commands starting with “toggle” (e.g., Toggle Screen Capture Mode).

Note: If the input box disappears after pressing Esc, the content will not be retained the next time it is invoked. Only after selecting and executing a command will the previous input content be retained upon the next invocation.

Directory Tree

I usually enable animations because “elegance never goes out of style.” This setting also affects scrolling in the “Settings” interface (previously, enabling smooth scrolling in the editor did not affect the scrolling behavior in the “Settings” interface or the directory tree).

Quick Open History

Pressing Cmd + P brings up the Quick Open input box, and remembering history is great. There’s also an option for whether the box automatically disappears when losing focus. In most scenarios, auto-disappearance is preferred, though occasionally it isn’t. For now, I’ll keep the default auto-disappearance.

Reduce Animation Effects in Workspace

With my 64GB M1 Max, reducing animations is unnecessary (the default is “auto,” which adapts based on system configuration, useful for syncing settings across multiple computers).

Font Smoothing

Similar to -webkit-font-smoothing: antialiased; in CSS, “default” displays the sharpest text on most non-retina screens (subpixel level), while “antialiased” provides pixel-level smoothing, which may make fonts appear thinner. See the comparison:

Although this setting is under the “Workspace” section, it also affects the editor area. Enabling “antialiased” makes fonts darker (lower contrast) and thinner in both the editor and workspace areas. I prefer the latter, so I enable it.

Note: “Subpixel level” does not mean finer than pixels but rather “below pixel level,” indicating a lower level, not a higher one.

Directory Tree Sticky

Extremely useful—it shows the current scroll path while scrolling. The only drawback is that adding a box-shadow would improve visual distinction:

The maximum sticky level can also be adjusted. The default is 7, which is sufficient (the editor’s default sticky level is 5).

Note: This setting also applies to the “Settings” interface (originally, the settings interface belongs to the workspace, not the editor):

I changed the directory tree indentation to 14 and prefer always showing the reference lines, as it helps locate files among many siblings:

Directory Navigation

Directory navigation is necessary, but file/folder icons are not needed. This significantly distinguishes them from arrays and classes within files, making it very useful:

Modified Tabs

Several related settings exist, such as displaying a highlight line above unsaved modified files:

By default, a dot is shown. Enabling this option displays both the dot and the line. After restarting the editor, only the blue line above remains (possibly a bug—it should work without restarting).

Effect:

Since the “dot” occupies part of the tab space, it reduces the room for tab content. Thus, enabling this option is recommended.

Mouse Navigation

This is a default option, but I’ll mention it: For mice with left-side buttons (for right-handed users, i.e., buttons 4 and 5), navigation becomes effortless and highly convenient.

Tab Pinning

Pinned tabs default to the left side of the editor group. However, placing them in a separate row would visually distinguish them from unpinned tabs, as shown here:

Note: By default, pinned tabs cannot be closed with the middle mouse button or Cmd + W (pressing these opens an unpinned tab instead of closing the pinned one). This behavior can be modified.

Tab Close Button

I’ve always used the left-hand cmd + w shortcut to close tabs, so this option can be disabled. Additionally, I’m more accustomed to double-clicking tabs to close them, but the official response indicates this feature won’t be implemented, as seen here:

Allow to double click on a tab to close it · Issue #52628 · microsoft/vscode Some of the editors like notepad++ provide Double Click to close a TAB. It would be a great edition to VS Code. https://github.com/Microsoft/vscode/issues/52628#issuecomment-420887497

Tab Wrap

When many tabs are open, scrolling through them becomes cumbersome and makes it hard to maintain an overview. I prefer wrapping tabs, which looks like this:

One awkward aspect is that the multi-line tabs created by wrapping might conflict with the “modified tab blue highlight” mentioned earlier (it’s unclear whether the blue line belongs to the tab above or below, requiring a moment to process, which isn’t intuitive). It’s a trade-off between displaying more tab content and maintaining clarity:

Tab Height

A compact layout helps with maintaining an overview and saving space.

Double-Click to Close Tab (?)

This option appears to be the “double-click to close tab” feature the official team claimed they wouldn’t implement (as mentioned above). Even after disabling the potentially conflicting “double-click to auto-expand editor groups,” this setting still doesn’t work. It’s unclear whether I misunderstood it or if it’s a bug.

Native Tabs

There are two related settings:

The first setting, when enabled, allows merging multiple project windows into a single window. The “Window” menu will then include a “Merge All Windows” option, making it convenient to switch between multiple projects within one window:

However, this disables the ability to use custom titles (though I don’t find this particularly useful). A custom title looks like this:

If the first setting is enabled, the second becomes ineffective, regardless of whether it’s set to “native” or “custom.” If the first setting is disabled and the second is set to “native,” neither “Merge All Windows” nor “Custom Title Bar” will be available (making the purpose of this setting unclear).

File Tree Drag-and-Drop

I often accidentally trigger this, leading to hundreds of unintended changes… so I’ve turned it off.

Auto-Collapse Search Results

By default, results are always expanded. However, if there are too many results (often because the search query isn’t fully entered yet), expanding them is unnecessary and can hinder the overview.

Additionally, if you haven’t added “excluded files” to the search bar, you might encounter an overwhelming number of results (e.g., the .next directory in a NextJS project), making this setting essential.

Note that the “expand”/“collapse” threshold of 10 files refers to the number of matching files within a single folder in the search results, not the total number of folders in the entire search:

Thus, if a folder contains too many matching files (causing it to collapse), it usually indicates the need to refine the search query.

Auto-Fill Search Box with Selected Text

Typically, when you select text, you want to search for it. The “Seed On Focus” option saves you a cmd + v step.

Note that this differs from the “search widget” behavior where selected text is automatically inserted when focusing on the search bar. In the editor, selecting text and then focusing on the search widget might not always be for searching—it could simply be to highlight matching text in the current editor for reference. Automatically replacing the search query in this case often doesn’t align with expectations.

However, if you select text and then focus on the search view (right panel), it’s likely for searching purposes.

Additionally, I find it helpful to see line numbers in search results to locate matches within their documents, so displaying line numbers is also necessary.

The “Smart Case” feature is a handy trick: if the query is all lowercase, it assumes you’re unsure about the exact name; if it includes uppercase letters (e.g., camelCase function names), it performs a case-sensitive search. Very useful.

Lastly, if the search box remembers the last input, it’s ideal for it to remain selected. If it doesn’t match your current intent, you can simply type over it. If the previous search is still relevant, even better: ↓

Ignore Global .ignore Files in Search

Git has a global default ignore feature. Enabling this option allows files and folders listed in it to be ignored during searches, which is usually necessary.

There’s also an option to enable ignore in parent directories. I’m not entirely sure what it means—possibly related to multi-level Git management—but I checked it anyway. Since we’re ignoring things, might as well:

Debugging and Testing

Admittedly, my technical skills are limited, so I rarely use VSCode’s debugging and testing features. I’ve only used them for debugging NodeJS applications like NextJS, where the experience is similar to Chrome. Since I don’t use these features often, I haven’t encountered any pain points or found any optimizations worth mentioning here.

File Modification Effects

In the line number column, you can choose to display differences as solid lines or “gutters,” as shown here:

I prefer solid lines, so I unchecked both of these options.

Disable Git Commit Button

To be honest, I’ve never used the commit button on the left—I always use the command line for Git operations—so I disabled this option.

Similarly, this button (which appears to be for GitHub Copilot, automatically generating commit messages) is also disabled. Especially for company projects where we’re required to include task/bug card numbers in commit messages, this “smart” feature becomes even more useless:

Extensions

Disable Notifications

I don’t need any extensions telling me what to do. If I need something, I’ll seek it out myself.

Terminal

Right-Click Behavior

Normally, you select text with the left mouse button and then right-click for context actions. But VSCode’s default behavior is to show the right-click menu after selecting content (a word). It works, but it’s unnecessary.

Terminal Maximum Lines

This isn’t a critical setting, but I occasionally need to review very old log information. With my 64GB of RAM, increasing this value doesn’t hurt.

Terminal Scroll Animation

While I love animations (elegant!), the terminal’s scroll animation seems to have some inertia, making it hard to control the scroll amount. It feels very different from the scrolling behavior in the editor or workspace, so I turned it off.

CSS/Less/Sass

Lint Duplicate Property Warnings

This is very useful. Sometimes you copy multiple property values (e.g., from browser-inspected styles) and then remove duplicates.

Git

Auto Stash

As shown in the image, the description is clear. It’s recommended to enable this to save a step in your workflow.

Third-Party Extensions

There’s not much to say here. If you’ve installed an extension, it’s because you have a specific need for it, so configure it accordingly.

GitLens

However, some plugins, like GitLens, can disable paid feature prompts. For example, when I (accidentally) check Git branch merge status, I might trigger a paid feature prompt. Thankfully, this can be turned off (kudos to the plugin developer for being considerate):

One Dark Pro

I love this feature—it makes method and function names stand out more clearly:

Closing Thoughts

After all these settings, remember: what works for you is what matters most. Here’s to efficient work and leaving the office early!

• Previous
  【Video】Streamline Your Blog Publishing Process with Notion Flow
• Next
  Watching Beijing Unicom IPTV on Apple TV