CA1802 documentation needs to warn about the downsides #40827
Labels
doc-enhancement
Improve the current content [org][type][category]
dotnet-fundamentals/svc
help wanted
Good for community contributors to help [up-for-grabs]
in-pr
This issue will be closed (fixed) by an active pull request.
Pri2
Type of issue
Missing information
Description
This rule suggests changing "static readonly" fields whose value is set to a compile time constant to "const" when possible.
For public members this is potentially risky if there is any chance these values might change in the future. This is because of how const values get copied into dependent assemblies when used, which does not happen with static readonly fields. This means that if the value might change in a later version of a library, and if when it changes, other libraries compiled against the older version might misbehave as a result of still using the old value, then this warning should be suppressed instead.
The documentation should really at least mention this concern. Of course, this only helps people who read the documentation, but for those who do, at least they become fully informed of the risks involved in following this analyzer's advice.
I will clarify that this analyzer's suggestion is always fine for members with net private accessibility, and is fine for members with net internal accessibility if no InternalsVisibleTo is present (or if those dlls are always built in the same solution, and bundled into the same package or is not packaged and both are deployed together).
That safety is because a whole assembly is compiled at once so the used values will inherently be consistent even if it changes in the future, (except for the super uncommon, and generally ignored edge case of multi-module assemblies).
Page URL
https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1802
Content source URL
https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca1802.md
Document Version Independent Id
6b33a042-4440-65b8-2d4c-ab980124eec0
Article author
@gewarren
Metadata
The text was updated successfully, but these errors were encountered: