A parameter name ends with an implementation detail suffix like List.
Adding suffixes like List to parameter names adds unnecessary clutter.
It is best to avoid them for cleaner, more readable code.
Parameter names should describe what they represent from a conceptual standpoint, not how they are implemented. The parameter type already provides implementation information.
Suffixing parameter names with implementation details like List, Array, or Dictionary clutters the code and makes it harder to read.
The type system already provides this information, so repeating it in the name is redundant.
Avoiding implementation detail suffixes in parameter names provides several important benefits:
-
Improved Readability: Parameter names without type suffixes are cleaner and easier to read. Developers can focus on what the parameter represents rather than how it is stored.
-
Better Abstraction: Names that describe the concept rather than the implementation make the code more flexible. If the implementation changes from a List to an IEnumerable, the name does not need to change.
-
Reduced Cognitive Load: Developers do not need to process redundant information when reading method signatures. The parameter type is already visible, so the name can focus on the semantic meaning.
-
Consistency with .NET Standards: The .NET Framework and most C# codebases avoid type suffixes in parameter names. Following this convention makes the code more familiar to other developers.
-
Clearer Intent: Parameter names that describe what they represent (like
itemsorusers) are more meaningful than names that describe how they are stored (likeitemListoruserArray).
To fix a violation of this rule, rename the parameter to remove the implementation detail suffix. Use a plural form or a more descriptive name that represents what the parameter contains conceptually.
For example, rename itemList to items, or userArray to users.
#pragma warning disable MiKo_1040
#pragma warning restore MiKo_1040