| Do | Prefer using collections over arrays in public APIs. |
| Do Not | Use read-only array fields. |
| Consider | Using jagged arrays instead of multidimensional arrays. |
| Do | Name custom attribute classes with the suffix “Attribute”. |
| Do | Apply the AttributeUsageAttribute to custom attributes. |
| Do | Provide settable properties for optional arguments. |
| Do | Provide get-only properties for required arguments. |
| Do | Provide constructor parameters to initialize properties corresponding to required arguments. |
| Avoid | Providing constructor parameters to initialize properties corresponding to the optional arguments. |
| Avoid | Overloading custom attribute constructors. |
| Do | Seal custom attribute classes, if possible. |
| Do Not | Use weakly typed collections in public APIs. |
| Do Not | Use ArrayList or List<T> in public APIs. |
| Do Not | Use Hashtable or Dictionary<TKey, Tvalue> in public APIs. |
| Do Not | Use IEnumerator<T>, IEnumerator, or any other type that implements either of these interfaces, except as the return type of the GetEnumerator method. |
| Do Not | Implement both IEnumerator<T> and the IEnumerable<T> on the same type. |
| Do | Use the least specialized type possible as a parameter type. |
| Avoid | Using ICollection<T> or ICollection as a parameter just to access the Count property. |
| Do Not | Provide settable collection properties |
| Do | Use Collection<T> or a subclass of Collection<T> for properties or return values representing read / write collections. |
| Do | Use ReadOnlyCollection<T> or a subclass of ReadOnlyCollection<T> for properties or return values representing read-only collections. |
| Consider | Using subclasses of generic base collections instead of using the collections directly. |
| Do | Return a subclass of Collection<T> or ReadOnlyCollection<T> from very commonly used methods and properties. |
| Consider | Using a keyed collection if the items stored in the collection have unique keys (names, Ids, etc.). |
| Do Not | Return null values from collection properties or from methods returning collections. |
| Do Not | Return snapshot collections from properties. |
| Do | Use either a snapshot collection or a live Ienumerable<T> to represent collections that are volatile (i.e., can change without explicitly modifying the collection). |
| Do | Prefer collections over arrays. |
| Consider | Using arrays in low-level APIs to minimize memory consumption and maximize performance. |
| Do | Use byte arrays instead of collections of bytes. |
| Do Not | Use arrays for properties if the property would have to return a new array (e.g., a copy of an internal array) every time the property getter is called. |
| Do Not | Inherit from non generic base collections such as CollectionBase. |
| Do | Implement IEnumerable<T> on strongly typed non generic collections (collections created before Generics were available). |
| Avoid | Implementing collection interfaces on types with complex APIs unrelated to the concept of a collection. |
| Do | Use the “Collection” suffix in names of abstractions implementing IEnumerable (or any of its descendants), unless the type also implements IDictionary or IDictionary<TKey, TValue>. |
| Do | Use the “Dictionary” suffix in names of abstractions implementing IDictionary or IDictionary<TKey, TValue>. |
| Avoid | Using any suffixes implying particular implementation, such as “LinkedList” or “Hashtable,” in names of collection abstractions. |
| Consider | Prefixing collection names with the name of the item type. |
| Consider | Using the “ReadOnly” prefix in names of read-only collections, if a corresponding writable collection might be added or already exists in the framework. |
| Do Not | Implement ICloneable. |
| Do Not | Use ICloneable in public APIs. |
| Consider | Defining the Clone method on types that need a cloning mechanism. |
| Do | Implement IEquatable<T> on value types. |
| Do | Follow the same guidelines as for overriding Object.Equals when implementing IEquatable<T>.Equals |
| Do | Override Object.Equals whenever implementing IEquatable<T>. |
| Consider | Overloading operator== and operator!= whenever implementing IEquatable<T>. |
| Do | Implement IEquatable<T> anytime you implement IComparable<T>. |
| Consider | Overloading comparison operators (<, >, <=, >=) whenever you implement IComparable<T>. |
| Do | Comply with the contract defined for Object.Equals when overriding the method. |
| Do | Override GetHashCode whenever you override Equals. |
| Consider | Implementing IEquatable<T> whenever overriding Object.Equals. |
| Do Not | Throw exceptions from Equals. |
| Do | Override Equals on value types. |
| Do | Provide an overload of Equals taking the value type parameter by implementing IEquatable<T>. |
| Consider | Overriding Equals to provide value equality if a reference type represents a value. |
| Do | Override GetHashCode if you override Object.Equals. |
| Do | Ensure that if the Object.Equals method returns true for any tow objects, GetHashCode returns the same value for these objects. |
| Do | Make every effort to ensure that GetHashCode generates a random distribution of numbers for all objects of a type. |
| Do | Ensure that GetHashCode returns exactly the same value regardless of any changes that are made to the object. |
| Avoid | Throwing exceptions from GetHashCode. |
| Do | Override ToString whenever an interesting human-readable string can be returned. |
| Do | Try to keep the string returned from ToString short. |
| Consider | Returning a unique string associated with the instance. |
| Do | Prefer a friendly name over a unique but not readable ID. |
| Do | String formatting based on the current thread culture when returning culture-dependent information. |
| Do | Provide overload ToString(string format), or implement IFormattable, if the string returned from ToString() is culture sensitive or there are various ways to format the string. |
| Do Not | Return an empty string or null from ToString. |
| Avoid | Throwing exceptions from ToString. |
| Do | Ensure that ToString has no observable side effects. |
| Do | Report security-sensitive information through an override of ToString only after demanding an appropriate permission. |
| Consider | Having the output of ToString be a valid input for any parsing methods on this type. |
| Do | Use System.Uri to represent URI and URL data. |
| Consider | Providing string-based overloads for most commonly used members with System.Uri parameters. |
| Do Not | Automatically overload all Uri-based members with a version that accepts a string. |
| Do | Call the Uri-based overloads if available. |
| Do Not | Store URI/URL data in a string. |
| Do Not | Use XmlNode or XmlDocument to represent XML data. Favor using instances of IXPathNavigable instead. |
| Do | Use XmlReader or IXPathNavigable as input or output for methods that accept or return XML. |
| Do | Implement IXPathNavigable on types representing an XML view of an underlying object model or data source. |
| Do Not | Subclass XmlDocument if you want to create a type representing an XML view of an underlying object model or data source. |
| Do Not | Overload one of the equality operators but not the other. |
| Do | Ensure that Object.Equals and the equality operators have exactly the same semantics and similar performance characteristics. |
| Avoid | Throwing exceptions from equality operators. |
| Do | Overload the equality operators on value types, if equality is meaningful. |
| Avoid | Overloading equality operators on mutable reference types. |
| Consider | Not overloading equality operators on reference types, even if you override Equals or implement IEquatable<T>. |
| Avoid | Overloading equality operators on reference types if the implementation would be significantly slower than that of reference equality. |