Improving the Spell Checker

Dante Gagne

Welcome to our latest blog post about the spell checker feature in Visual Studio 17.6 preview 2! We’re excited to share with you the latest improvements we’ve made to this feature, which was first introduced in the Visual Studio 17.5 preview releases for C#, C++, and markdown files. We’ve received an overwhelming amount of valuable feedback from developers like you, which has helped shape and refine this feature before its release to the release channel.

The Visual Studio editor with the Spell Checker enabled. An identifier "DetailChekkForIssues" has the letters "Chekk" underlined in blue and a context menu offers to rename "Chekk" to "DetailCheckForIssues". Elsewhere in the screenshot, a string contains a URL of "", but none of it is being flagged as a spelling error, and later in the code, a string literal includes strings like hello\nworld and hello\tworld which correctly handle the escape characters while looking for misspelled words.

If you’re new to the spell checker feature, check out our earlier blog post for an introduction. Otherwise, let’s dive into the exciting enhancements in Visual Studio 17.6 preview 2!

Programming Language Specific Dictionaries

The biggest feedback we heard was concerning false positives. The spell checker uses the same dictionaries as the spoken languages that were detected. We added heuristics to compensate for how code uses those words, so constructs like HelloWorld would be properly spell checked, but developers use many words that aren’t part of our spoken languages. Words like ‘guid’ or ‘args’ are commonly found in code documents but were getting flagged as misspelled words by the spell checker.

In this update, we’ve partnered with the C++ and C# teams to add exclusion dictionaries specific to those languages that detect words are commonly used in those languages. This should significantly reduce the number of false positives, especially when commenting out pieces of code. Later in this post, we’ll discuss the switch we’ve added to editorconfig that can control this behavior, should users want to disable it.

Exclusion Dictionary Encoding

Another issue many folks ran into was around the encoding of the exclusion dictionaries used by the spell checker. Visual Studio will use the exclusion dictionary specified by the spelling_exclusion_path switch in your editorconfig file or an “exclusion.dic” file in your %localappdata%\Microsoft\VisualStudio\<Version> directory if a switch can’t be found. In either case, the spell-checking APIs required the exclusion file to have “UTF-16 with BOM” encoding to work correctly. We got multiple reports of the encoding becoming corrupted, particularly when users manually modified these files to remove excluded words.

With this update, we’ve improved the way Visual Studio works with exclusion files. UTF-16 encoding is no longer necessary, so users should be able to modify exclusion dictionaries without running into encoding issues.

Better Special Case Handling

We also appreciate the folks who caught some cases we didn’t think of. We added additional improvements for some special cases based on this feedback:

  • Strings that contain URLs (E.g., “https://...” or ”mailto:..”.) will not be spell checked over the entire string.
  • Backslashes will omit the subsequent character from spell-checking. For instance “\nhello” will no longer be flagged as a spelling error since the ‘n’ is omitted and ‘hello’ is a correctly spelled word.
  • Recommendations that include punctuation will no longer be recommended. For instance “misc.” will no longer be recommended as it could cause code that won’t compile.

Customizing the Spell Checker

We added the spelling_use_default_exclusion_dictionary switch for editorconfig in this update. For your convenience, here’s the full list of available options:

spelling_languages = _language_[,_language_] (Example: = en-us,fr-fr)

  • This lists the languages for Visual Studio to use. In this example, Visual Studio would only use the en-us and fr-fr dictionaries when checking for spelling issues. Note that the fr-fr language pack must be installed on the user’s machine or Visual Studio will incorrectly flag any French words as spelling errors.

spelling_checkable_types = strings,identifiers,comments (Example: = identifiers,comments)

  • This controls what Visual Studio should check. In this example, Visual Studio would check identifiers and comments for misspelled words but wouldn’t check inside strings.

spelling_error_severity = error OR warning OR information OR hint (Example: = error)

  • This controls the severity Visual Studio will assign to spelling errors in the error list. In this example, spelling errors will be displayed as errors.

spelling_exclusion_path = absolute OR relative path to exclusion dictionary. (Example: = .\exclusion.dic)

  • This allows you to create your own exclusion dictionary to specify words you consider to be correctly spelled. The exclusion dictionary is a simple text file that can be checked into source control where each line in the file contains a single word that should be considered a properly spelled word. In this example, the first time the spell checker is run against any file in the solution, Visual Studio will check for an exclusion.dic file in the same directory as the .sln file (for a C# project) or in the root directory (for a C++ directory). If no file exists, the spell checker will create one. Then, whenever you choose to ignore a word, it will be added to this exclusion.dic file. Visual Studio will consider any word that appears in this exclusion.dic file as a correctly spelled word.

spelling_use_default_exclusion_dictionary = true OR false (Example: = spelling_use_default_exclusion_dictionary = false)

  • This controls whether the language specific exclusion dictionary will be used. When set to false, any words specified in the C++ or C# specific exclusion dictionaries will NOT be used. The default is true.

Your feedback matters!

We greatly value the feedback we’ve received from our users and are thrilled with the positive reactions we’ve received. Your input has directly influenced the improvements we’ve made to Visual Studio, and we’re eager to continue evolving the product to meet your needs. We have an ambitious roadmap ahead, and your feedback will help us prioritize our efforts. Let’s keep the conversation going on Developer Community, and thank you for being an essential part of the Visual Studio community!