Visual Studio Code: Code Spell Checker
Whatever your IDE of choice, there are things you can do to enhance your development experience, improve your productivity and maximise quality. But when your repository contains not only code, but documentation and configuration documents as well, it can be challenging. Then it's a case of diving into the documentation and configuring to the max. This blog post covers some learning I've gained over the last week, specifically for configuring spell checking in Visual Studio Code.
Code Spell Checker is a great tool for avoiding typos in your repository. It's a standard extension I've used for some time and one which has prevented mistakes in documentation, as well as typos in code itself.
How It Works
This extension reviews all opened files and adds "info" messages to the Problems view for any spelling problems. It also contributes a Spell Checker view with spelling issues. As well as cross-referencing words in various language and technical dictionaries, it also uses rules for camel case and snake case words.
Admittedly, this may not suit some developers' preferences around variable names. If so, you are likely to get a lot of errors notified and it may create too much noise. But I'm happy with those rules for variables, method names and keywords.
Even still, it has generated a lot of warnings for me. There are various options for configuration, but there's not a single "right" solution. So it makes sense to document my approach to configuration.
Ignoring Words
There will always be certain words that are not in usual dictionaries. And it's no surprise that Code Spell Checker provides various ways to do this. The right approach may vary depending on your use case.
If the words are specific to the project you're working on, and you're working in a team, a good approach is to add the words to the workspace. They can be added to the normal VS Code workspace settings. But it's important to bear in mind that this means adding the ".vscode/settings.json" file to your repository, which may also include other settings you don't want. They can also be added to a custom directory in the workspace, but this also needs enabling in the settings.json for the repository.
If you're a lone developer or the words are used across all your projects, adding them to your user settings may work for you. This adds them to your global VS Code settings.json, under a section called cSpell.userWords. AGain, you can also add them to a dictionary and load them from there.
GitIgnore Challenges
In one project, I'm using the VS Code workspace settings.json. But the repository is also used for Mac users, using a devcontainer. This is typically also in .vscode directory of the repository. So we get a conflict: we want to include the settings.json from .vscode directory, but not other files. The good news is that's pretty straightforward:
This includes the settings.json from that directory, but only that file.
Ignoring Files
cSpell ignores certain files for specific languages, like package.json. But with VoltScript and MKDocs, we have files not in that list. These can be ignored in user settings again. The extensions settings has a section under "Files, Folders, and Workspaces" called Ignore Paths. When entered as a filename, e.g. atlas.json or mkdocs.yml, they are resolved relative to the workspace, which is easy to manage. But it means the whole team need to standardise on having this set up.
Checking Unopened Files
It's important to bear in mind something I mentioned earlier, that it only looks at files opened during the current session. There is a command line Node.js tool by the same team who built the VS Code extension. But you will need to convert the VS Code extension settings for custom dictionaries. I've not tried that, but it looks like it can be done from the VS Code extension by using the Command Palette. This could be worth investigating if you want to check the whole repository but don't want to open all the files.
YMMV
Obviously as a team, you'll need to decide on the approach that works best for your use case. Having a dictionary in a separate central repository may also be an option. But the right approach will depend on the preferences of the developers involved.
There are a host of additional configuration options that may or may not be relevant, so it's worth digging into the settings and the documentation.