CA1704: Identifiers should be spelled correctly
Applies to: Visual Studio Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
Item | Value |
---|---|
RuleId | CA1704 |
Category | Microsoft.Naming |
Breaking change | Breaking |
Cause
The name of an identifier contains one or more words that are not recognized by the Microsoft spelling checker library. This rule does not check constructors or special-named members such as get and set property accessors.
Rule description
This rule parses the identifier into tokens and checks the spelling of each token. The parsing algorithm performs the following transformations:
Uppercase letters start a new token. For example, MyNameIsJoe tokenizes to "My", "Name", "Is", "Joe".
For multiple uppercase letters, the last uppercase letter starts a new token. For example, GUIEditor tokenizes to "GUI", "Editor".
Leading and trailing apostrophes are removed. For example, 'sender' tokenizes to "sender".
Underscores signify the end of a token and are removed. For example, Hello_world tokenizes to "Hello", "world".
Embedded ampersands are removed. For example, for&mat tokenizes to "format".
Language
The spell checker currently checks only against English-based culture dictionaries. You can change the culture of your project in the project file, by adding the CodeAnalysisCulture element.
For example:
<Project ...>
<PropertyGroup>
<CodeAnalysisCulture>en-AU</CodeAnalysisCulture>
Important
If you set the culture to anything other than an English-based culture, this code analysis rule is silently disabled.
How to fix violations
To fix a violation of this rule, correct the spelling of the word or add the word to a custom dictionary.
To add words to a custom dictionary
Name the custom dictionary XML file CustomDictionary.xml. Place the dictionary in the installation directory of the tool, the project directory, or in the directory that is associated with the tool under the profile of the user (%USERPROFILE%\Application Data\...). To learn how to add the custom dictionary to a project in Visual Studio, see How to: Customize the Code Analysis Dictionary.
Add words that should not cause a violation under the Dictionary/Words/Recognized path.
Add words that should cause a violation under the Dictionary/Words/Unrecognized path.
Add words that should be flagged as obsolete under the Dictionary/Words/Deprecated path. See the related rule topic CA1726: Use preferred terms for more information.
Add exceptions to the acronym casing rules to the Dictionary/Acronyms/CasingExceptions path.
The following is an example of the structure of a custom dictionary file:
<Dictionary>
<Words>
<Unrecognized>
<Word>cb</Word>
</Unrecognized>
<Recognized>
<Word>stylesheet</Word>
<Word>GotDotNet</Word>
</Recognized>
<Deprecated>
<Term PreferredAlternate="EnterpriseServices">ComPlus</Term>
</Deprecated>
</Words>
<Acronyms>
<CasingExceptions>
<Acronym>CJK</Acronym>
<Acronym>Pi</Acronym>
</CasingExceptions>
</Acronyms>
</Dictionary>
When to suppress warnings
Suppress a warning from this rule only if the word is intentionally misspelled and the word applies to a limited set of the library. Correctly spelled words reduce the learning curve that is required for new software libraries.
Related rules
- CA2204: Literals should be spelled correctly
- CA1703: Resource strings should be spelled correctly
- CA1709: Identifiers should be cased correctly
- CA1708: Identifiers should differ by more than case
- CA1707: Identifiers should not contain underscores
- CA1726: Use preferred terms