I’ve been using VS Code for quite some time now. In fact, given the nature of my work recently I’ve found myself spending more time in VS Code than in VS 2017 over the past several months. The “out-of-the-box”, “stock” experience with VS Code is truly fantastic and has provided me with just about all the functionality I’ve needed.

Sure, I’ve added some extensions such as C#, mssql, Babel JavaScript, and transformer to address some gaps but by and large, I’ve found the experience to be more than sufficient for my needs. That said, I recently attended a talk that began by highlighting a dozen or so of the interesting configuration options that can be set to tweak the experience.

Given that I’ve never really paid much attention to the settings I thought I should dive in, look over the nearly 500 settings, and highlight a few which I found most interesting. Although the vast majority are pretty typical for an editor there are plenty that can have a significant impact on the way we work so without further ado, here are my picks for the top 15 most interesting VS Code settings!

15. window.title

Out-of-the-box, VS Code’s title bar provides minimal information about what’s being edited. The information provided might be sufficient for small projects or individual files but as projects grow it might not be enough. For example, how many files named index.js does your latest node.js project contain?

window.title gives us a relatively straightforward way to customize the information shown in the title bar by providing us with a series of variables we can include in a string template. The default settings document details the variables so I won’t go into detail about them here but I will say that I’ve found the following quite useful:

"${appName}${separator}${rootName}${separator}${activeEditorMedium}"

14. workbench.tips.enabled

After opening VS Code for the first time and exploring the UI a bit you’re likely to close all of the editor windows and stumble upon this nice watermark image and a few tips for returning to a productive state. Over time however, you’re likely to internalize most of the tips and you might not want to see them any more. By changing workbench.tips.enabled to false you can rid yourself of them and get rid of some of the clutter.

It’s a subtle change but I really like just having the faint VS logo.

13. update.channel

If you do any number of presentations that rely on VS Code or you like to control when your software updates are installed the update.channel setting will likely be of interest to you. Setting this value to none and restarting the editor will prevent any new releases from being installed and potentially interfering with any of your demos!

Once you’ve set update.channel to none and are ready to apply any available updates you can do so by selecting the Check for Updates option under the Code menu on the Mac or the Help menu on Windows.

12. markdown.styles

I do much of my writing in markdown. Even write most of my blog posts start off in markdown before I move them to WordPress when I’m ready to publish. As convenient as that is, I often find that I’d like to customize how the preview window renders the text, be it for my stylistic preference or to match the styles in a given project. That’s where the markdown.styles setting comes in.

The help text displayed for the markdown.styles setting in the master settings file reads as follows:

A list of URLs or local paths to CSS style sheets to use from the markdown preview. Relative paths are interpreted relative to the folder open in the explorer. If there is no open folder, they are interpreted relative to the location of the markdown file. All ‘\’ need to be written as ‘\’.

I point this out because it reveals a number of intricacies about the setting. First, it takes an array of file names. This allows us to split our CSS into several files or allow the CSS to vary by project. Next, the file names are all relative to either the current markdown file OR the folder open in the VS Code Explorer. Since the paths are relative we can share CSS between markdown files or projects based on our file organization structure.

Note: You’ll need to close and re-open the preview after changing this setting or the referenced CSS for the changes to be reflected in the preview window.

11. editor.fontLigatures

Although changing the font is something that one would expect from any text editor, I particularly appreciate that VS Code allows us to control whether ligatures are rendered for the fonts that support them.

One such font that I like is Fira Code, a programming font specifically designed with ligatures in mind. In Fira Code, ligatures are used for a number of multi-character operators such as equality, inequality, piping, and so on as a single glyph rather than several thus allowing the code to [arguably] look a bit cleaner. The underlying characters all remain intact, I just think it just looks better.

Not everyone likes the ligatures for a multitude of reasons so they’re disabled by default but by changing the editor.fontLigatures setting to true we can take advantage of them in VS Code. Of course, if you enable the setting and decide you don’t like them, you can always return the value to its default.

10. editor.renderWhitespace

Although I don’t spend much time in F# these days one thing I got used to was caring about seeing whitespace in my code since whitespace is significant there. I got so used to seeing whitespace in my code that I even turned on the feature in Word for my more formal writing. Unfortunately, showing whitespace in the full Visual Studio is a binary proposition; you either see all whitespace characters or none. I’ve often wished for some balance between the two options.

VS Code’s editor.renderWhitespace setting takes this capability beyond what Visual Studio traditionally offers by providing a third option, boundary, which offers what I consider to be the best of both worlds. The boundary setting essentially shows leading and trailing whitespace while ignoring single whitespace characters between words or syntax elements.

In the screenshot which features some JavaScript you can see the leading whitespace rendered as dots but the spaces in the code itself are ignored leading to a more natural appearance.

9. editor.cursorStyle

This is another setting with a subtle visual effect that can greatly affect your experience when using VS Code.

By default, the text cursor is rendered as a solid vertical bar but there are plenty of other styles in other editors. In VS Code we can change the editor.cursorStyle setting to adjust the cursor to something else that we may be more accustomed to, be it a vertical line, underscore, or even a box.

Setting	Effect
block
block-outline
line
line-thin
underline
underline-thin

There’s also an editor.cursorBlinking setting which controls how the cursor blinks. I prefer the solid or default blink values but you can also choose smooth, phase, and expand.

I encourage you to experiment with various combinations of the editor.cursorStyle and editor.cursorBlinking settings to choose one that works best for you. I thought the expanding block-outline was fun for a bit but found it pretty distracting overall. Now I’m back to using a boring solid line.

8. git.autofetch

If you’re working on a team, chances are that your teammates are pushing changes to the same remote repository that you are. The git.autoFetch setting toggles whether VS Code automatically fetches those changes from the remote so you can see what’s happening in the repository without integrating the changes immediately. I think it’s a nice feature but if you enable it for daily use you may consider disabling it when working on a plane. Oops!

7. editor.minimap.*

VS Code’s minimap is a nice feature which shows you an overview of your code’s structure. It comes with a few customization options that I think greatly enhance its usefulness.

First is editor.minimap.renderCharacters. By default the minimap renders a pixelated view that attempts to replicate the characters in your code. Given how small the box is, I don’t find it particularly useful to render that way since most of the information is lost. Instead, I prefer to disable that option so the map renders blocks that represent the structure.

Next is editor.minimap.showSlider. This setting merely toggles when the region of the file currently visible in the editor window is highlighted in the map. By default, this is set to show only when the pointer is over the map. I tend to leave this setting alone but it can also be set to always so that it’s always shown.

Another interesting minimap setting is editor.minimap.maxColumn. Changing this value affects the minimap’s width based on the number of textual columns in the code. The default is 120.

We can also control whether the minimap appears on the right or left side of the code listing with the editor.minimap.side setting. By default the minimap appears on the right. I’ve played with both sides and see merits to both. When on the right, the minimap takes advantage of existing whitespace but it often quite some distance from the code. On the other hand, placing the minimap on the left increases the margin size but places the map much closer to most of the code. I tend to keep the minimap on the right to take advantage of that existing whitespace.

Finally, the minimap isn’t for everyone so like so many other VS Code features, you can turn it off by setting editor.minimap.enabled to false.

6. debug.internalConsoleOptions

Most of my work in VS Code centers around JavaScript applications and I’ve found the debugger in particular to be quite pleasant to work with. One thing that I found a bit troublesome at first though was how erratically the debug console window appeared to behave when I started a new debugging session. Fortunately, we can tame it a bit by changing the debug.internalConsoleOptions setting. This setting takes one of three values:

Value	Effect
neverOpen	Does not automatically open the debug console
openOnFirstSessionStart	Opens the debug console when the first debugging session starts
openOnSessionStart	Opens the debug console every time a debugging session starts

By default, debug.internalConsoleOptions is set to openOnFirstSessionStart but I prefer openOnSessionStart if for no reason other than starting each debugging session at a consistent place.

5. debug.openExplorerOnEnd

Much like the debug.internalConsoleOption setting, debug.openExplorerOnEnd controls affects VS Code’s behavior when working with debugging sessions. Where the debug.internalConsoleOption setting can surface the debug console when debugging starts, debug.openExplorerOnEnd surfaces the main explorer window when debugging ends. Be default this behavior is disabled but it can be convenient for remaining focused on your project structure whenever you return to editing.

4. files.exclude

When we open a folder in VS Code the explorer shows us a listing of that folder’s contents. Most of the time there are certain files or subfolders (such as .git) that we don’t want to see. VS Code’s files.exclude setting is an object that indicates whether certain glob patterns should be shown.

By default, the major version control system folders are hidden along with some other “special” folders (such as .DS_Store) that are used by the underlying operating system.

A related setting is search.exclude which behaves similar to files.exclude except that it specifies glob patterns to exclude from VS Code’s built-in search capabilities. Paths you may choose to exclude from the search feature would be things like the node_modules folder.

What I think makes this pair of settings so interesting is that search.exclude inherits the values from files.exclude so those globs are automatically excluded from search results while other patterns can still be shown in the explorer panel but excluded from searches.

3. editor.multiCursorModifier

One of my most loved VS Code features is its support for multiple cursors. I love that when my decade-old JavaScript habits kick in and I declare a series of values with var that I can click in multiple, non-sequential places in my code and replace change them to const or let. The problem is, I always seem to hold the wrong key, particularly when jumping between my Mac and Windows devices.

The editor.multiCursorModifier setting defaults to alt but I much prefer the ctrlCmd value. Now, regardless of which laptop I’m on, I press what is essentially the same key.

2. files.hotExit

Another of my favorite VS Code features is hot exit. Hot exit is VS Code’s ability to remember unsaved changes when VS Code is closed. This has proven fantastically useful for me when I’ve been keeping a scratchpad going and need to reboot to apply the latest system updates or accidentally close my VS Code windows.

By default, hot exit is set to trigger onExit but you can customize the behavior by changing the files.hotExit setting to off to disable, or onExitAndWindowClose to apply the effect to editor windows not tied to a particular folder.

1. files.autoSave

Finally we reach what has quickly become one of my favorite VS Code features – auto save. Although disabled by default VS Code gives us plenty of variety when it comes to managing this behavior via the files.autoSave setting.

To automatically save all changed files when we focus away from VS Code we can use the onWindowChange option. Similarly, we can use the onFocusChange value to save any changes when focus leaves the editor. And then there’s my personal favorite: autoSaveDelay which saves any changes after some interval specified by the files.autoSaveDelay setting. By default, this automatically saves changes every second but you can adjust it to your needs.

Although I definitely prefer the autoSaveDelay option I will offer one word of warning – don’t use it with nodemon or anything else that automatically rebuilds/reloads a project. Since you’ll likely be in the middle of typing some expression or statement when the interval hits, those processes are likely going to hit code that’s a work-in-progress and throw some errors.

Conclusion

So there they are – my 15 picks for most interesting VS Code settings. I did intentionally exclude some extension-specific settings from this list but I think these are definitely some of the most impactful settings for a variety of environments.

Did I miss any settings you find especially interesting? Let me know and I’ll see about putting together another list.