|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Do not name enum values 'Reserved'
This rule assumes that an enumeration member with a name that contains "reserved" is not currently used but is a placeholder to be renamed or removed in a future version. Renaming or removing a member is a breaking change. You should not expect users to ignore a member just because its name contains "reserved" nor can you rely on users to read or abide by documentation. Furthermore, because reserved members appear in object browsers and smart integrated development environments, they can cause confusion as to which members are actually being used.
Instead of using a reserved member, add a new member to the enumeration in the future version. In most cases, the addition of the new member is not a breaking change, as long as the addition does not cause the values of the original members to change.
There are a limited number of cases where the addition of a member is a breaking change even when the original members retain their original values. Primarily, the new member cannot be returned from existing code paths without breaking callers that use a switch (Select in Visual Basic) statement on the return value that encompasses the entire member list and that throw an exception in the default case. A secondary concern is that client code might not handle the change in behavior from reflection methods such Enum.IsDefined. Accordingly, if the new member needs to be returned from existing methods or there is a known application incompatibility because of poor reflection usage, then the only non-breaking solution is to add a new enumeration containing the original and new members, and to mark the original enumeration with the System.ObsoleteAttribute attribute. Follow the same procedure for any externally visible types or members that expose the original enumeration.