Edit

Share via

CA1720: Identifiers should not contain type names

  • Article
Property Value
Rule ID CA1720
Title Identifiers should not contain type names
Category Naming
Fix is breaking or non-breaking Breaking
Enabled by default in .NET 9 No

Cause

The name of a parameter in a member contains a data type name.

-or-

The name of a member contains a language-specific data type name.

By default, this rule only looks at externally visible members, but this is configurable.

Rule description

Names of parameters and members are better used to communicate their meaning than to describe their type, which is expected to be provided by development tools. For names of members, if a data type name must be used, use a language-independent name instead of a language-specific one. For example, instead of the C# type name int, use the language-independent data type name, Int32.

Each discrete token in the name of the parameter or member is checked against the following language-specific data type names in a case-insensitive manner:

  • Bool
  • WChar
  • Int8
  • UInt8
  • Short
  • UShort
  • Int
  • UInt
  • Integer
  • UInteger
  • Long
  • ULong
  • Unsigned
  • Signed
  • Float
  • Float32
  • Float64

In addition, the names of a parameter are also checked against the following language-independent data type names in a case-insensitive manner:

  • Object
  • Boolean
  • Char
  • String
  • SByte
  • Byte
  • UByte
  • Int16
  • UInt16
  • Int32
  • UInt32
  • Int64
  • UInt64
  • IntPtr
  • Ptr
  • Pointer
  • UInptr
  • UPtr
  • UPointer
  • Single
  • Double
  • Decimal
  • Guid

How to fix violations

If fired against a parameter:

Replace the data type identifier in the name of the parameter with either a term that better describes its meaning or a more generic term, such as 'value'.

If fired against a member:

Replace the language-specific data type identifier in the name of the member with a term that better describes its meaning, a language-independent equivalent, or a more generic term, such as 'value'.

When to suppress warnings

Occasional use of type-based parameter and member names might be appropriate. However, for new development, no known scenarios occur where you should suppress a warning from this rule. For libraries that have previously shipped, you might have to suppress a warning from this rule.

Suppress a warning

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable CA1720
// The code that's violating the rule is on this line.
#pragma warning restore CA1720

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.CA1720.severity = none

For more information, see How to suppress code analysis warnings.

Configure code to analyze

Use the following option to configure which parts of your codebase to run this rule on.

You can configure this option for just this rule, for all rules it applies to, or for all rules in this category (Naming) that it applies to. For more information, see Code quality rule configuration options.

Include specific API surfaces

You can configure which parts of your codebase to run this rule on, based on their accessibility. For example, to specify that the rule should run only against the non-public API surface, add the following key-value pair to an .editorconfig file in your project:

dotnet_code_quality.CAXXXX.api_surface = private, internal