As I’ve already mentioned several times before, I’m not exactly infatuated with Microsoft’s Visual Studio Code editor. It’s not bad — in fact from a feature perspective it offers more than most other editors — but the fact that it’s Electron-based and will spawn multiple V8 instances that gobble up memory as if it’s their job makes me shy away from it.
That being said, VS Code has become so ubiquitous that often times various tooling is only supported for it. A great example is for Puppet, which only makes tooling available as a VS Code extension. While I wished that wasn’t the case, the tooling is so good that I’m not going to avoid using it and making my coworkers deal with code that has bugs, uses deprecated functionality, and is improperly formatted just because it doesn’t happen to be available in a different editor. This probably has the exact effect Microsoft is hoping for in that I’ll then find myself using VS Code for other things simply because I don’t want to bother with switching editors… though I’ll always use IntelliJ for anything Java-related because doing otherwise is pure madness.
Like any self-respecting tech geek, I have Strong Opinions™ about how I want my editor to behave. As a result, while it doesn’t require the type of configuration that something like Neovim does, I’ve still spent some time tweaking my VS Code settings and subsequently backing those up since it would be more than a little annoying to have to recreate them from scratch on a different device.
One nice aspect of VS Code is that all of the settings are available as JSON. This is a holdover from the days when all of the settings had to be defined in JSON because there was no GUI for them; today you can manage the majority of these from a UI, but JSON is still supported… and in some cases is required. I personally like it since it makes taking a snapshot of your settings very easy. I keep mine saved in a Gist, though they’re also directly reproduced here since they aren’t particularly long:
{
"workbench.colorTheme": "Tokyo Night Storm",
"editor.fontFamily": "'Monaspace Argon', monospace",
"security.workspace.trust.banner": "never",
"security.workspace.trust.startupPrompt": "never",
"security.workspace.trust.untrustedFiles": "open",
"security.workspace.trust.enabled": false,
"editor.fontLigatures": "'calt', 'liga', 'dlig', 'ss01', 'ss02', 'ss03', 'ss04', 'ss05', 'ss06', 'ss07', 'ss08'",
"editor.fontSize": 14,
"editor.wordWrap": "on",
"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true,
"editor.rulers": [
80
],
"[python]": {
"editor.defaultFormatter": "ms-python.black-formatter",
"editor.formatOnSave": true
},
"python.analysis.typeCheckingMode": "basic",
"editor.cursorSurroundingLines": 8,
"files.trimFinalNewlines": true,
"redhat.telemetry.enabled": false,
"editor.cursorBlinking": "phase",
"workbench.tree.indent": 20,
"python.defaultInterpreterPath": "./.venv/bin/python"
}
I won’t go through all of the settings since that would be boring and some have actually been covered in other posts, but to start off the Tokyo Night theme is one I’ve been obsessed with for about a year. I use it in VS Code, iTerm2, and Neovim. I found a fork of it for Sublime that I tried out, but unfortunately a lot of the extra eye candy supported by Sublime wasn’t defined for it.
I’ve already covered the font in-depth, so feel free to read that post if you want more information about Monaspace.
I imagine there are some scenarios where the workspace trust settings in VS Code provide some sort of value, but for me they only ever serve as an annoyance; I’m honestly surprised that they’re enabled by default since literally everyone I know simply turns them off immediately. I disabled everything for them that ever bugged me about something and have yet to regret the decision.
The setting to trim trailing whitespace is one that I honestly think should be enabled by default since I can’t imagine when you’d actually want to leave something like that lingering behind. I configure all of my editors to do this, and I can’t tell you how many PRs I’ve opened for projects at work with a minor change where it looks like I modified almost every line of the file since hitting save trimmed trailing whitespace from nearly everything in it. I could disable the feature prior to saving those changes, but honestly… the whitespace should be trimmed.
Similarly, the setting to insert a final newline is a nice quality of life feature since I pretty much exclusively work in Unix-like operating systems these days, and it’s unreasonably irritating to cat a file just to have my shell prompt start immediately after the end of the content because there wasn’t a trailing newline. This is another setting that I almost think should be on by default considering that even most developers I know who use Windows are executing their code in the Windows Subsystem for Linux.
The ruler at 80 columns is something I use as a guideline rather than a hard rule. Even Pylint doesn’t trigger a warning until more than 100 columns, but I like to make myself think about how long the line will be when I start to cross beyond 80. Of course, it’s irrelevant in something like Python because I use black to format my code automatically, but in other environments it can be useful.
As far as the setting for cursor blinking goes, I just find phase to be the most pleasant. I actually didn’t even think about this in VS Code until I happened to one day realize this was what I set Sublime to and checked to see if VS Code had an equivalent. Tangentially related, if you’re curious on my opinion for the cursor in Neovim, I like the default setting with the wide cursor in normal and visual mode, but the thin cursor in insert mode. It basically takes the ambiguity out of everything.
The setting for tree indent is probably the most meaningful that I have for the default editor (e.g. that isn’t related to a plugin.) VS Code shows a nice file tree to the left of the active workspace by default, but to me it was always difficult to tell in a large project where files really were. If I had several nested folders and some of them were expanded, it was difficult to tell what folder a given file was in.
This setting simply increases how far things are indented in the tree when they belong to a folder, and I can’t stress enough what a difference it made when working in large projects. I went from struggling to figure out where a file lived to operating almost as quickly as I can think… though clicking files is nowhere near as awesome as using something like Telescope. 😎