My 7 Recommended Settings for Visual Studio Code

If we’re spending so much time working in IDEs, then we should at least feel comfortable while doing so

Photo by Clément Hélardot on Unsplash

Visual Studio Code has become a popular choice for all kinds of developers in the last few years. There’s a lot to like about VS Code: It supports a variety of languages; there are many free extensions available; it is frequently updated, and the source code is available on GitHub.

After a short stint with Eclipse, I quickly embraced IntelliJ IDEA (Ultimate) as my most favorite IDE. In the last two years, I’ve become a fan of VS Code as well, though. As someone who uses both VS Code and IntelliJ IDEA regularly, I appreciate what each of them brings to the table. Still, I sometimes found myself looking to tweak VS Code to mirror certain behaviours of IntelliJ IDEA.

While extensions add new functionality, VS Code already has a lot of functionality built-in that can be customized to your liking. These are the settings that I tweaked in VS Code to improve my developer experience. Of course, this list is highly subjective as everyone has different backgrounds and preferences.

• Linked Editing
• Minimap
• Autosave
• Git input validation subject length
• Window title
• Window zoom level
• Preview editor

How To Change Settings in VS Code

You can access the VS Code settings using either the menu or using the Command Palette.

Accessing the settings through the menu

Accessing the settings through the Command Palette

I prefer to use the Command Palette (on a Mac you can press ⇧⌘P to open it). On the one hand, I often use it to not only change settings but to also create a new Git branch or reload the window. On the other hand, it allows you to open the settings as JSON as well. This is handy as it allows you to copy and paste settings with ease.

Being able to search VS Code settings is much appreciated as there are a lot of settings (and if you have installed some extensions then you get even more settings).

Without further ado, let’s have a look at settings I have customized to my liking.

editor.linkedEditing — Editor: Linked Editing

Controls whether the editor has linked editing enabled. Depends on whether the language, related symbols, e.g. HTML tags, are updated while editing.

I’ve set it to true. As someone who likes to do frontend development, I work with HTML templates a lot. By default, VS Code will autoclose HTML tags — which is a nice convenience feature. However, it annoyed me that if I changed a tag (e.g. a <a> to a <button>) VS Code would not update the other tag as well.

Missing this feature that IntelliJ has built in, I recently searched through the web. I couldn’t imagine VS Code not supporting this feature. Luckily, VS Code supports this feature too — which makes working with HTML easier.

editor.minimap.enabled — Editor › Minimap: Enabled

Controls whether the minimap is shown.

I’ve set it to false. In my opinion, it creates visual clutter rather than actually help me while working in a file. I do appreciate that the minimap also allows you to scroll quickly through your file, though.

The minimap in VS Code (on the right side)

files.autoSave — Auto Save

Controls autosave of dirty editors.

off - to disable auto save.
afterDelay - to save files after a configured delay (default 1000 ms).
onFocusChange - to save files when focus moves out of the editor of the dirty file.
onWindowChange - to save files when the focus moves out of the VS Code window.

I’ve set it to onWindowChange. By default, VS Code requires an explicit action to save your changes to disk. I usually don’t like to save manually — we all know the memes of forgetting to save. onWindowChange is a reasonable choice, in my opinion, as changes will only be saved when the focus moves out of the VS Code window. For instance, you modify the styling of an HTML element through VS Code and switch to your browser to see the change without having to save it manually. It feels a little magical as long as you have a fast machine.

git.inputValidationSubjectLength - Git: Input Validation Subject Length

Controls the commit message subject length threshold for showing a warning.

I’ve set it to 72. It is a good practice to keep the commit subject short and concise and put details into the extended description. 72 is neither particularly high nor too short. I’m aiming to set this to a lower number in the future, though (as you can see below, GitHub warns you when your commit summary exceeds 50 characters).

Commit message subject validation in GitHub

window.title — Window: Title

Controls the window title based on the active editor. Variables are substituted based on the context:

${activeEditorShort}: the file name (e.g. myFile.txt).
${activeEditorMedium}: the path of the file relative to the workspace folder (e.g. myFolder/myFileFolder/myFile.txt).
${activeEditorLong}: the full path of the file (e.g. /Users/Development/myFolder/myFileFolder/myFile.txt).
${activeFolderShort}: the name of the folder the file is contained in (e.g. myFileFolder).
${activeFolderMedium}: the path of the folder the file is contained in, relative to the workspace folder (e.g. myFolder/myFileFolder).
${activeFolderLong}: the full path of the folder the file is contained in (e.g. /Users/Development/myFolder/myFileFolder).
${folderName}: name of the workspace folder the file is contained in (e.g. myFolder).
${folderPath}: file path of the workspace folder the file is contained in (e.g. /Users/Development/myFolder).
${rootName}: name of the workspace (e.g. myFolder or myWorkspace).
${rootPath}: file path of the workspace (e.g. /Users/Development/myWorkspace).
${appName}: e.g. VS Code.
${remoteName}: e.g. SSH
${dirty}: a dirty indicator if the active editor is dirty.
${separator}: a conditional separator (" - ") that only shows when surrounded by variables with values or static text.

I’ve set it to ${activeEditorLong}${separator}${rootName}. We have a lot of space in the window title, so why not use it to show where we are.

Making use of the space in the window title area by showing the full path to the currently edited file

window.zoomLevel — Window: Zoom Level

Adjust the zoom level of the window. The original size is 0 and each increment above (e.g. 1) or below (e.g. -1) represents zooming 20% larger or smaller. You can also enter decimals to adjust the zoom level with a finer granularity.

I’ve set it to 0.8. While you can zoom in and zoom out like in any browser (Remember: VS Code is built on Electron which means it’s basically Chromium), you can adjust the zoom level with higher precision by using the settings. This changed setting makes reading code more pleasant to my eyes.

workbench.editor.enablePreview — Workbench › Editor: Enable Preview

Controls whether opened editors show as preview. Preview editors do not stay open and are reused until explicitly set to be kept open (e.g. via double-click or editing). They show up with an italic font style.

I’ve set it to false. I get the idea behind this feature, but in most cases, I just don’t need it. By disabling this feature, a normal editor is opened when clicking a file in the file explorer.

Conclusion

Thanks for reading this short post about my favorite VS Code tweaks. The extensibility and flexibility of VS Code are strong reasons to use VS Code. I’d be interested in hearing about your favorite settings in VS Code. Let me know in the comments.

PS: If you’re interested in the VS Code theme I use, then check out the Material Theme.