S3L0007: No types in names¶
A name says what it holds, not its type: users, never userList.
| Category | Snail |
| Severity | warning — an error under TreatWarningsAsErrors, which every Snail project builds with |
| Analyzer | Naming in Snail.Sdk.Analyzers |
| Code fix | none |
What it reports¶
A property, field, local (a declaration, a using, a for), parameter or foreach variable whose name ends in its
type's word, after a lowercase letter, when the declared type is of that kind:
| Declared type | Reported endings |
|---|---|
string |
String, Str |
| an array | Array, Arr, List |
IDictionary<,> or IReadOnlyDictionary<,> |
Dictionary, Dict, Map |
IEnumerable<T> |
List, Collection, Array |
The match is case-sensitive: userList (a List<User>) is reported, playlist is not, and neither is a string named
checkList.
What it leaves alone¶
Overrides, interface implementations and their parameters (their names are someone else's), and members released in
PublicAPI.Shipped.txt.
Why¶
The type is already in the declaration and in every editor's hover; the name has room for what the value means.
How to fix¶
Name the plural or the role: userList → users, nameString → name, priceMap → pricesBySku.
Suppressing it¶
Fix the code rather than silence the rule: the rule is part of the standard every Snail repository keeps. Where one place truly must differ, suppress that place and say why:
[SuppressMessage("Snail", "S3L0007:No types in names", Justification = "<why this place differs>")]A NoWarn in a project or props file would hide the rule from every new line too; the
conformance check reports one as migration debt (S3LC0017).