Guidelines.xml

<?xml version="1.0" encoding="utf-8"?>
<Guidelines>
  <guideline key="Ch03_2de296a" severity="CONSIDER" section="Coding" subsection="Arrays">CONSIDER checking the array length before indexing into an array rather than assuming the length.</guideline>
  <guideline key="Ch03_6020c2f" severity="CONSIDER" section="Coding" subsection="Arrays">CONSIDER using the index from end operator (^) rather than Length - 1 with C# 8.0 or higher.</guideline>
  <guideline key="Ch05_fd422b3" severity="DO" section="Coding" subsection="Arrays">DO use parameter arrays when a method can handle any number—including zero—of additional arguments.</guideline>
  <guideline key="Ch03_bb28ad5" severity="CONSIDER" section="Coding" subsection="Arrays">CONSIDER checking for null before accessing an array rather than assuming there is an array instance.</guideline>
  <guideline key="Ch12_3bebbda" severity="AVOID" section="Coding" subsection="Arrays">"AVOID unsafe array covariance. Instead, CONSIDER converting the array to the read-only interface IEnumerable&lt;T&gt;, which can be safely converted via covariant conversions."</guideline>
  <guideline key="Ch18_b0ac9c3" severity="CONSIDER" section="Coding" subsection="Assemblies">CONSIDER applying AssemblyFileVersionAttribute and AssemblyCopyrightAttribute to provide additional information about the assembly.</guideline>
  <guideline key="Ch18_4ebbbb5" severity="DO" section="Coding" subsection="Assemblies">DO apply the AttributeUsageAttribute class to custom attributes.</guideline>
  <guideline key="Ch18_969dbd2" severity="DO" section="Coding" subsection="Assemblies">DO provide constructor parameters to initialize properties on attributes with required properties. Each parameter should have the same name (albeit with different casing) as the corresponding property.</guideline>
  <guideline key="Ch18_d8ee2a8" severity="DO" section="Coding" subsection="Assemblies">DO provide get-only properties (without public setters) on attributes with required property values.</guideline>
  <guideline key="Ch18_8291b23" severity="DO" section="Coding" subsection="Assemblies">DO apply AssemblyVersionAttribute to assemblies with public types.</guideline>
  <guideline key="Ch18_c26ec43" severity="DO" section="Coding" subsection="Assemblies">"DO apply the following information assembly attributes: System.Reflection.AssemblyCompanyAttribute, System.Reflection.AssemblyCopyrightAttribute, System.Reflection.AssemblyDescriptionAttribute, and System.Reflection.AssemblyProductAttribute."</guideline>
  <guideline key="Ch18_b930cb1" severity="DO" section="Coding" subsection="Assemblies">DO name custom attribute classes with the suffix Attribute.</guideline>
  <guideline key="Ch04_c448a56" severity="DO" section="Coding" subsection="Branches">DO use the while loop when the number of loop iterations is not known in advance and a counter is not needed.</guideline>
  <guideline key="Ch04_6ec1332" severity="DO NOT" section="Coding" subsection="Branches">"DO NOT use continue as the jump statement that exits a switch section. This is legal when the switch is inside a loop, but it is easy to become confused about the meaning of break in a later switch section."</guideline>
  <guideline key="Ch04_48641bf" severity="DO" section="Coding" subsection="Branches">DO use the for loop when the number of loop iterations is known in advance and the “counter” that gives the number of iterations executed is needed in the loop.</guideline>
  <guideline key="Ch04_f8b2290" severity="CONSIDER" section="Coding" subsection="Branches">CONSIDER refactoring the method to make the control flow easier to understand if you find yourself writing for loops with complex conditionals and multiple loop variables.</guideline>
  <guideline key="Ch04_d810859" severity="CONSIDER" section="Coding" subsection="Branches">CONSIDER using an if-else statement instead of an overly complicated conditional expression.</guideline>
  <guideline key="Ch04_8768539" severity="AVOID" section="Coding" subsection="Branches">AVOID using goto.</guideline>
  <guideline key="Ch01_d57eb7e" severity="DO" section="Coding" subsection="Classes">DO use PascalCasing for all class names.</guideline>
  <guideline key="Ch01_5e914b9" severity="DO" section="Coding" subsection="Classes">DO name classes with nouns or noun phrases.</guideline>
  <guideline key="Ch12_46f316c" severity="DO" section="Coding" subsection="Classes">DO place multiple generic semantically equivalent classes into a single file if they differ only by the number of generic parameters.</guideline>
  <guideline key="Ch12_b939a91" severity="AVOID" section="Coding" subsection="Classes">AVOID shadowing a type parameter of an outer type with an identically named type parameter of a nested type.</guideline>
  <guideline key="Ch23_1cbd746" severity="DO NOT" section="Coding" subsection="Classes">DO NOT unnecessarily replicate existing managed classes that already perform the function of the unmanaged API.</guideline>
  <guideline key="Ch10_6da0739" severity="DO" section="Coding" subsection="Classes">DO implement IDisposable to support possible deterministic finalization on classes with finalizers.</guideline>
  <guideline key="Ch14_287ceb3" severity="DO" section="Coding" subsection="Classes">DO pass the instance of the class as the value of the sender for nonstatic events.</guideline>
  <guideline key="Ch10_e13f0a0" severity="DO" section="Coding" subsection="Comments">"DO provide XML comments on public APIs when they provide more context than the API signature alone. This includes member descriptions, parameter descriptions, and examples of calling the API."</guideline>
  <guideline key="Ch01_29e0d70" severity="DO" section="Coding" subsection="Comments">DO favor writing clearer code over entering comments to clarify a complicated algorithm.</guideline>
  <guideline key="Ch01_b91db37" severity="DO NOT" section="Coding" subsection="Comments">DO NOT use comments unless they describe something that is not obvious to someone other than the developer who wrote the code.</guideline>
  <guideline key="Ch10_351d63c" severity="DO NOT" section="Coding" subsection="Conversions">DO NOT provide an implicit conversion operator if the conversion is lossy.</guideline>
  <guideline key="Ch09_c60ba06" severity="AVOID" section="Coding" subsection="Conversions">AVOID direct enum/string conversions where the string must be localized into the user’s language.</guideline>
  <guideline key="Ch10_77f1997" severity="DO NOT" section="Coding" subsection="Conversions">DO NOT throw exceptions from implicit conversions.</guideline>
  <guideline key="Ch10_9d5e586" severity="DO" section="Coding" subsection="Dispose()">DO unregister any AppDomain.ProcessExit events during dispose.</guideline>
  <guideline key="Ch10_922019d" severity="DO" section="Coding" subsection="Dispose()">DO invoke a base class’s Dispose() method from the Dispose(bool disposing) method if one exists.</guideline>
  <guideline key="Ch10_81b73ae" severity="DO" section="Coding" subsection="Dispose()">DO implement IDisposable on types that own disposable fields (or properties) and dispose of those instances.</guideline>
  <guideline key="Ch10_b461e4f" severity="CONSIDER" section="Coding" subsection="Dispose()">"CONSIDER ensuring that an object becomes unusable after Dispose() is called. After an object has been disposed, methods other than Dispose() (which could potentially be called multiple times) should throw an ObjectDisposedException."</guideline>
  <guideline key="Ch10_433eb77" severity="DO" section="Coding" subsection="Dispose()">DO invoke a base class’s Dispose() method when overriding Dispose().</guideline>
  <guideline key="Ch10_2ce2a05" severity="AVOID" section="Coding" subsection="Dispose()">"AVOID calling Dispose() on owned objects that have a finalizer. Instead, rely on the finalization queue to clean up the instance."</guideline>
  <guideline key="Ch10_91544e8" severity="DO" section="Coding" subsection="Dispose()">DO implement the dispose pattern on objects with resources that are scarce or expensive.</guideline>
  <guideline key="Ch10_6d5cc11" severity="DO" section="Coding" subsection="Dispose()">"DO keep Dispose() simple, focusing on the resource cleanup required by finalization."</guideline>
  <guideline key="Ch10_824bd4c" severity="DO" section="Coding" subsection="Dispose()">DO ensure that Dispose() is idempotent (it should be possible to call Dispose() multiple times).</guideline>
  <guideline key="Ch10_394b4e6" severity="DO" section="Coding" subsection="Dispose()">DO call System.GC.SuppressFinalize() from Dispose() to avoid repeating resource cleanup and delaying garbage collection on an object.</guideline>
  <guideline key="Ch09_5638d27" severity="CONSIDER" section="Coding" subsection="Enums">"CONSIDER adding new members to existing enums, but keep in mind the compatibility risk."</guideline>
  <guideline key="Ch09_cc7b10e" severity="AVOID" section="Coding" subsection="Enums">"AVOID creating enums that represent an “incomplete” set of values, such as product version numbers."</guideline>
  <guideline key="Ch09_bf80755" severity="AVOID" section="Coding" subsection="Enums">AVOID creating flag enums where the zero value has a meaning other than “no flags are set.”</guideline>
  <guideline key="Ch09_a2194dc" severity="AVOID" section="Coding" subsection="Enums">AVOID enums that contain a single value.</guideline>
  <guideline key="Ch09_210817d" severity="DO" section="Coding" subsection="Enums">"DO provide a value of 0 (none) for simple enums, knowing that 0 will be the default value when no explicit initialization is provided."</guideline>
  <guideline key="Ch09_590f85a" severity="AVOID" section="Coding" subsection="Enums">AVOID creating “reserved for future use” values in an enum.</guideline>
  <guideline key="Ch09_ae9fd04" severity="DO" section="Coding" subsection="Enums">DO use the FlagsAttribute to mark enums that contain flags.</guideline>
  <guideline key="Ch17_3e78c90" severity="CONSIDER" section="Coding" subsection="Enums">CONSIDER using the Enumerable.Empty&lt;T&gt;() method instead.</guideline>
  <guideline key="Ch09_cbd14ef" severity="DO" section="Coding" subsection="Enums">DO provide a None value equal to 0 for all flag enums.</guideline>
  <guideline key="Ch10_ad5ebdb" severity="AVOID" section="Coding" subsection="Equality">AVOID overriding the equality-related members on mutable reference types or if the implementation would be significantly slower with such overriding.</guideline>
  <guideline key="Ch10_4ad6b26" severity="AVOID" section="Coding" subsection="Equality">AVOID using the equality comparison operator (==) from within the implementation of the == operator overload.</guideline>
  <guideline key="Ch10_7a89bb4" severity="DO" section="Coding" subsection="Equality">DO implement all the equality-related methods when implementing IEquitable.</guideline>
  <guideline key="Ch09_bbc6c0d" severity="DO" section="Coding" subsection="Equality">"DO override the equality operators (Equals(), ==, and !=) and GetHashCode() on value types if equality is meaningful. (Also consider implementing the IEquatable&lt;T&gt; interface.)"</guideline>
  <guideline key="Ch17_a1ca8bf" severity="DO" section="Coding" subsection="Equality">DO ensure that custom comparison logic produces a consistent “total order.”</guideline>
  <guideline key="Ch11_21b2430" severity="DO" section="Coding" subsection="Exceptions">DO use throw; rather than throw &lt;exception object&gt; inside a catch block.</guideline>
  <guideline key="Ch10_7b8b338" severity="DO NOT" section="Coding" subsection="Exceptions">DO NOT throw exceptions from finalizer methods.</guideline>
  <guideline key="Ch19_a22b724" severity="CONSIDER" section="Coding" subsection="Exceptions">"CONSIDER registering an unhandled exception event handler for debugging, logging, and emergency shutdown purposes."</guideline>
  <guideline key="Ch11_afd8eb7" severity="DO" section="Coding" subsection="Exceptions">"DO throw an ArgumentException or one of its subtypes if bad arguments are passed to a member. Prefer the most derived exception type (e.g., ArgumentNullException), if applicable."</guideline>
  <guideline key="Ch11_de2ae32" severity="DO NOT" section="Coding" subsection="Exceptions">"DO NOT throw a System.Exception, System.NullReferenceException, or System.ApplicationException."</guideline>
  <guideline key="Ch11_a4a2dfc" severity="DO" section="Coding" subsection="Exceptions">"DO use nameof for the paramName argument passed into argument exception types that take such a parameter. Examples of such exceptions include ArgumentException, ArgumentOutOfRangeException, and ArgumentNullException."</guideline>
  <guideline key="Ch11_557411c" severity="AVOID" section="Coding" subsection="Exceptions">AVOID exception reporting or logging lower in the call stack.</guideline>
  <guideline key="Ch11_cc2ea7b" severity="DO NOT" section="Coding" subsection="Exceptions">DO NOT over-catch. Exceptions should be allowed to propagate up the call stack unless it is clearly understood how to programmatically address those errors lower in the stack.</guideline>
  <guideline key="Ch11_2ece07c" severity="CONSIDER" section="Coding" subsection="Exceptions">CONSIDER catching a specific exception when you understand why it was thrown in a given context and can respond to the failure programmatically.</guideline>
  <guideline key="Ch11_6b6691b" severity="AVOID" section="Coding" subsection="Exceptions">AVOID catching System.Exception or System.SystemException except in top-level exception handlers that perform final cleanup operations before rethrowing the exception.</guideline>
  <guideline key="Ch11_fdbe66c" severity="DO" section="Coding" subsection="Exceptions">DO use exception filters to avoid rethrowing an exception from within a catch block.</guideline>
  <guideline key="Ch11_eab9daf" severity="DO NOT" section="Coding" subsection="Exceptions">DO NOT throw a System.SystemException or an exception type that derives from it.</guideline>
  <guideline key="Ch11_cc8bdbb" severity="AVOID" section="Coding" subsection="Exceptions">AVOID throwing exceptions from exception filters.</guideline>
  <guideline key="Ch05_1e83a49" severity="DO" section="Coding" subsection="Exceptions">DO report execution failures by throwing exceptions rather than returning error codes.</guideline>
  <guideline key="Ch05_a71ffdd" severity="DO NOT" section="Coding" subsection="Exceptions">DO NOT have public members that return exceptions as return values or an out parameter. Throw exceptions to indicate errors; do not use them as return values to indicate errors.</guideline>
  <guideline key="Ch05_15169c1" severity="DO NOT" section="Coding" subsection="Exceptions">"DO NOT use exceptions for handling normal, expected conditions; use them for exceptional, unexpected conditions."</guideline>
  <guideline key="Ch05_0f98c19" severity="AVOID" section="Coding" subsection="Exceptions">"AVOID catching and logging an exception before rethrowing it. Instead, allow the exception to escape until it can be handled appropriately."</guideline>
  <guideline key="Ch05_75f9029" severity="AVOID" section="Coding" subsection="Exceptions">AVOID catching exceptions for which the appropriate action is unknown. It is better to let an exception go unhandled than to handle it incorrectly.</guideline>
  <guideline key="Ch05_888a64e" severity="DO" section="Coding" subsection="Exceptions">"DO throw exceptions that describe which exceptional circumstance occurred, and if possible, how to prevent it."</guideline>
  <guideline key="Ch11_2da3d93" severity="DO" section="Coding" subsection="Exceptions">DO use caution when rethrowing different exceptions.</guideline>
  <guideline key="Ch05_34bdd36" severity="DO" section="Coding" subsection="Exceptions">DO favor try/finally and avoid using try/catch for cleanup code.</guideline>
  <guideline key="Ch05_cab2aca" severity="AVOID" section="Coding" subsection="Exceptions">AVOID explicitly throwing exceptions from finally blocks. (Implicitly thrown exceptions resulting from method calls are acceptable.)</guideline>
  <guideline key="Ch05_6f18913" severity="DO" section="Coding" subsection="Exceptions">DO prefer using an empty throw when catching and rethrowing an exception so as to preserve the call stack.</guideline>
  <guideline key="Ch11_3e7fa54" severity="DO" section="Coding" subsection="Exceptions">DO specify the inner exception when wrapping exceptions.</guideline>
  <guideline key="Ch06_f672cce" severity="AVOID" section="Coding" subsection="Exceptions">AVOID throwing exceptions from property getters.</guideline>
  <guideline key="Ch06_1807a61" severity="DO" section="Coding" subsection="Exceptions">DO preserve the original property value if the property throws an exception.</guideline>
  <guideline key="Ch11_b33eb2a" severity="DO" section="Coding" subsection="Exceptions">"DO target developers as the audience for exceptions, identifying both the problem and the mechanism to resolve it, where possible."</guideline>
  <guideline key="Ch11_7babf31" severity="CONSIDER" section="Coding" subsection="Exceptions">CONSIDER wrapping specific exceptions thrown from the lower layer in a more appropriate exception if the lower-layer exception does not make sense in the context of the higher-layer operation.</guideline>
  <guideline key="Ch11_8dbcb70" severity="CONSIDER" section="Coding" subsection="Exceptions">CONSIDER providing exception properties for programmatic access to extra information relevant to the exception.</guideline>
  <guideline key="Ch11_d9dd166" severity="AVOID" section="Coding" subsection="Exceptions">AVOID exception filters with logic that might implicitly change over time.</guideline>
  <guideline key="Ch11_ebd61fb" severity="AVOID" section="Coding" subsection="Exceptions">AVOID deep exception hierarchies.</guideline>
  <guideline key="Ch11_dee4a04" severity="DO" section="Coding" subsection="Exceptions">DO make exceptions runtime-serializable.</guideline>
  <guideline key="Ch23_3969d9e" severity="DO" section="Coding" subsection="Exceptions">DO use the SetLastErrorAttribute on Windows to turn APIs that use SetLastError error codes into methods that throw Win32Exception.</guideline>
  <guideline key="Ch11_0c3e99d" severity="DO" section="Coding" subsection="Exceptions">DO name an exception classes with the “Exception” suffix.</guideline>
  <guideline key="Ch11_1f39540" severity="DO NOT" section="Coding" subsection="Exceptions">DO NOT create a new exception type if the exception would not be handled differently than an existing CLR exception. Throw the existing framework exception instead.</guideline>
  <guideline key="Ch11_f4a7c97" severity="DO" section="Coding" subsection="Exceptions">DO provide a parameterless constructor on all custom exception types. Also provide constructors that take a message and an inner exception.</guideline>
  <guideline key="Ch11_a87831d" severity="DO" section="Coding" subsection="Exceptions">DO create a new exception type to communicate a unique program error that cannot be communicated using an existing CLR exception and that can be programmatically handled in a different way than any other existing CLR exception type.</guideline>
  <guideline key="Ch06_bb622bd" severity="DO" section="Coding" subsection="Fields">DO use public static readonly modified fields for predefined object instances prior to C# 6.0.</guideline>
  <guideline key="Ch06_fda9a36" severity="AVOID" section="Coding" subsection="Fields">AVOID changing a public readonly modified field in pre-C# 6.0 to a read-only automatically implemented property in C# 6.0 (or later) if version API compatibility is required.</guideline>
  <guideline key="Ch06_d19d6d7" severity="AVOID" section="Coding" subsection="Fields">AVOID publicly exposed nested types. The only exception is if the declaration of such a type is unlikely or pertains to an advanced customization scenario.</guideline>
  <guideline key="Ch08_5f240f5" severity="DO" section="Coding" subsection="Fields">DO use PascalCasing and a leading underscore and an “I” prefix for interface names.</guideline>
  <guideline key="Ch06_d75e3ef" severity="AVOID" section="Coding" subsection="Fields">AVOID naming fields with camelCase.</guideline>
  <guideline key="Ch06_30a3139" severity="AVOID" section="Coding" subsection="Fields">AVOID constant fields for values that will change over time.</guideline>
  <guideline key="Ch06_8030561" severity="DO" section="Coding" subsection="Fields">DO use constant fields for values that will never change.</guideline>
  <guideline severity="DO" section="Coding" subsection="Fields">DO name fields with PascalCase and a leading underscore.</guideline>
  <guideline key="Ch06_d80065c" severity="DO" section="Coding" subsection="Fields">DO declare all instance fields as private (and expose them via a property).</guideline>
  <guideline key="Ch06_389b3f9" severity="CONSIDER" section="Coding" subsection="Fields">CONSIDER initializing static fields inline rather than explicitly using static constructors or declaration assigned values.</guideline>
  <guideline key="Ch05_0d6dee5" severity="CONSIDER" section="Coding" subsection="Files">CONSIDER organizing the directory hierarchy for source code files to match the namespace hierarchy.</guideline>
  <guideline key="Ch10_9564067" severity="CONSIDER" section="Coding" subsection="Files">CONSIDER creating a folder structure that matches the namespace hierarchy.</guideline>
  <guideline key="Ch06_a3f55af" severity="DO NOT" section="Coding" subsection="Files">DO NOT place more than one class in a single source file.</guideline>
  <guideline key="Ch09_5980324" severity="CONSIDER" section="Coding" subsection="Flags">CONSIDER using the default 32-bit integer type as the underlying type of an enum. Use a smaller type only if you must do so for interoperability; use a larger type only if you are creating a flags enum with more than 32 flags.</guideline>
  <guideline key="Ch09_22c339b" severity="CONSIDER" section="Coding" subsection="Flags">CONSIDER providing special values for commonly used combinations of flags.</guideline>
  <guideline key="Ch09_c440ab9" severity="DO" section="Coding" subsection="Flags">DO use powers of 2 to ensure that all flag combinations are represented uniquely.</guideline>
  <guideline key="Ch04_f78b688" severity="AVOID" section="Coding" subsection="Increment/decrement">AVOID confusing usage of the increment and decrement operators.</guideline>
  <guideline key="Ch04_49c83ed" severity="DO" section="Coding" subsection="Increment/decrement">"DO be cautious when porting code between C, C++, and C# that uses increment and decrement operators; C and C++ implementations need not follow the same rules as C#."</guideline>
  <guideline key="Ch08_c27f99b" severity="CONSIDER" section="Coding" subsection="Interfaces">CONSIDER interfaces over abstract classes for polymorphic behavior starting with in C# 8.0/.NET Core 3.0 and abstract classes prior to C# 8.0.</guideline>
  <guideline key="Ch08_90bad7b" severity="DO NOT" section="Coding" subsection="Interfaces">DO NOT add abstract members to an interface that has already been published.</guideline>
  <guideline key="Ch08_6cb51d2" severity="AVOID" section="Coding" subsection="Interfaces">AVOID using “marker” interfaces with no members; use attributes instead.</guideline>
  <guideline key="Ch08_d270819" severity="CONSIDER" section="Coding" subsection="Interfaces">CONSIDER defining an interface if you need to support its functionality on types that already inherit from some other type.</guideline>
  <guideline key="Ch08_7131c23" severity="DO" section="Coding" subsection="Interfaces">DO use an additional interface when properties are necessary for extending polymorphic behavior for framework support prior to .NET Core 3.0.</guideline>
  <guideline key="Ch08_f759236" severity="DO" section="Coding" subsection="Interfaces">DO use extension methods when the interface providing the polymorphic behavior is not under your control.</guideline>
  <guideline key="Ch08_c3f1da8" severity="CONSIDER" section="Coding" subsection="Interfaces">CONSIDER using extension methods or an additional interface in place of default interface members when adding methods to a published interface.</guideline>
  <guideline key="Ch15_f656e44" severity="DO" section="Coding" subsection="Methods">DO use a collection’s Count property (if available) instead of calling the System.Linq.Enumerable.Count() method.</guideline>
  <guideline key="Ch10_282b7b2" severity="DO NOT" section="Coding" subsection="Methods">"DO NOT throw exceptions from implementations of GetHashCode(), Equals(), ==, and !=."</guideline>
  <guideline key="Ch15_90555d7" severity="DO" section="Coding" subsection="Methods">DO use System.Linq.Enumerable.Any() rather than calling patents.Count() when checking whether there are more than zero items.</guideline>
  <guideline key="Ch16_843c44d" severity="CONSIDER" section="Coding" subsection="Methods">"CONSIDER using the standard query operators (method call form) if the query involves operations that do not have a query expression syntax, such as Count(), TakeWhile(), or Distinct()."</guideline>
  <guideline key="Ch12_e8af4ce" severity="AVOID" section="Coding" subsection="Methods">AVOID misleading the caller with generic methods that are not as type-safe as they appear.</guideline>
  <guideline key="Ch10_b806065" severity="DO" section="Coding" subsection="Methods">"DO use the same algorithm when implementing Equals(), ==, and !=."</guideline>
  <guideline key="Ch10_0f702bd" severity="DO" section="Coding" subsection="Methods">"DO refactor a finalization method to call the same code as IDisposable, perhaps simply by calling the Dispose() method."</guideline>
  <guideline key="Ch14_ae03c5b" severity="DO" section="Coding" subsection="Methods">DO use the null-conditional operator prior to calling Invoke() starting in C# 6.0.</guideline>
  <guideline key="Ch13_cb612be" severity="AVOID" section="Coding" subsection="Methods">AVOID the anonymous method syntax in new code; prefer the more compact lambda expression syntax.</guideline>
  <guideline key="Ch11_5e5b567" severity="CONSIDER" section="Coding" subsection="Methods">CONSIDER terminating the process by calling System.Environment.FailFast() if the program encounters a scenario where it is unsafe to continue execution.</guideline>
  <guideline key="Ch10_588aded" severity="DO" section="Coding" subsection="Methods">"DO implement GetHashCode(), Equals(), the == operator, and the != operator together—not one of these without the other three."</guideline>
  <guideline key="Ch10_acb628c" severity="DO" section="Coding" subsection="Methods">DO implement finalizer methods only on objects with resources that don't have finalizers but still require cleanup.</guideline>
  <guideline key="Ch23_ac15501" severity="DO" section="Coding" subsection="Methods">"DO create public managed wrappers around unmanaged methods that use the conventions of managed code, such as structured exception handling."</guideline>
  <guideline key="Ch23_a0fe82e" severity="DO" section="Coding" subsection="Methods">DO declare extern methods as private or internal.</guideline>
  <guideline key="Ch23_193ed1d" severity="DO" section="Coding" subsection="Methods">DO extend SafeHandle or implement IDisposable and create a finalizer to ensure that unmanaged resources can be cleaned up effectively.</guideline>
  <guideline key="Ch06_9373c04" severity="AVOID" section="Coding" subsection="Methods">"AVOID frivolously defining extension methods, especially on types you don’t own."</guideline>
  <guideline key="Ch23_3189bfc" severity="DO" section="Coding" subsection="Methods">"DO provide public wrapper methods that use managed conventions such as structured exception handling, use of enums for special values, and so on."</guideline>
  <guideline key="Ch15_22fd754" severity="DO NOT" section="Coding" subsection="Methods">DO NOT call an OrderBy() following a prior OrderBy() method call. Use ThenBy() to sequence items by more than one value.</guideline>
  <guideline key="Ch05_c6009f8" severity="DO" section="Coding" subsection="Methods">DO give methods names that are verbs or verb phrases.</guideline>
  <guideline key="Ch16_22981e5" severity="DO" section="Coding" subsection="Miscellaneous">"DO use query expression syntax to make queries easier to read, particularly if they involve complex from, let, join, or group clauses."</guideline>
  <guideline key="Ch05_2ea0636" severity="DO" section="Coding" subsection="Miscellaneous">"DO treat parameter names as part of the API, and avoid changing the names if version compatibility between APIs is important."</guideline>
  <guideline key="Ch06_0f313e5" severity="DO" section="Coding" subsection="Miscellaneous">DO name the source file with the name of the public type it contains.</guideline>
  <guideline key="Ch06_b418973" severity="DO" section="Coding" subsection="Miscellaneous">DO use the same name for constructor parameters (camelCase) and properties (PascalCase) if the constructor parameters are used to simply set the property.</guideline>
  <guideline key="Ch10_155c67f" severity="AVOID" section="Coding" subsection="Miscellaneous">AVOID referencing other objects that are not being finalized during finalization.</guideline>
  <guideline key="Ch17_ffa4134" severity="CONSIDER" section="Coding" subsection="Miscellaneous">CONSIDER using nonrecursive algorithms when iterating over potentially deep data structures.</guideline>
  <guideline key="Ch10_2cab586" severity="CONSIDER" section="Coding" subsection="Miscellaneous">CONSIDER registering the finalization code with the AppDomain.ProcessExit to increase the probability that resource cleanup will execute before the process exits.</guideline>
  <guideline key="Ch13_b42a787" severity="AVOID" section="Coding" subsection="Miscellaneous">AVOID capturing loop variables in anonymous functions.</guideline>
  <guideline key="Ch14_ec7dc09" severity="DO" section="Coding" subsection="Miscellaneous">DO check that the value of a delegate is not null before invoking it.</guideline>
  <guideline key="Ch17_5bc0611" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT represent an empty collection with a null reference.</guideline>
  <guideline key="Ch14_300569e" severity="DO" section="Coding" subsection="Miscellaneous">DO check that the value of a delegate is not null before invoking it (possibly by using the null-conditional operator in C# 6.0).</guideline>
  <guideline key="Ch14_3675ac8" severity="DO" section="Coding" subsection="Miscellaneous">DO pass null as the sender for static events.</guideline>
  <guideline key="Ch02_da95aff" severity="DO" section="Coding" subsection="Miscellaneous">DO favor consistency rather than variety within your code.</guideline>
  <guideline key="Ch23_d560942" severity="DO" section="Coding" subsection="Miscellaneous">DO use ref parameters rather than pointer types when possible.</guideline>
  <guideline key="Ch23_e606562" severity="DO" section="Coding" subsection="Miscellaneous">DO use delegate types that match the signature of the desired method when an unmanaged API requires a function pointer.</guideline>
  <guideline key="Ch14_4241a49" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT pass null as the value of the eventArgs argument.</guideline>
  <guideline key="Ch02_b86a9e2" severity="DO" section="Coding" subsection="Miscellaneous">DO rely on System.WriteLine() and System.Environment.NewLine rather than \n to accommodate Windows-specific operating system idiosyncrasies with the same code that runs on Linux and iOS.</guideline>
  <guideline key="Ch09_b25f010" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT include “sentinel” values (such as a value called Maximum); such values can be confusing to the user.</guideline>
  <guideline key="Ch04_9ec5eda" severity="DO NOT" section="Coding" subsection="Miscellaneous">"DO NOT use a constant for any value that can possibly change over time. The value of pi and the number of protons in an atom of gold are constants; the price of gold, the name of your company, and the version number of your program can change."</guideline>
  <guideline key="Ch02_bd492fc" severity="DO" section="Coding" subsection="Miscellaneous">"DO use the C# keyword rather than the BCL name when specifying a data type (e.g., string rather than String)."</guideline>
  <guideline key="Ch01_9cc676b" severity="DO NOT" section="Coding" subsection="Miscellaneous">"DO NOT use Hungarian notation (that is, do not encode the type of a variable in its name)."</guideline>
  <guideline key="Ch01_1724fff" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT use abbreviations or contractions within identifier names.</guideline>
  <guideline key="Ch01_1f465b0" severity="DO NOT" section="Coding" subsection="Miscellaneous">"DO NOT use any acronyms unless they are widely accepted, and even then use them consistently."</guideline>
  <guideline key="Ch01_a611579" severity="DO" section="Coding" subsection="Miscellaneous">"DO capitalize both characters in two-character acronyms, except for the first word of a camelCased identifier."</guideline>
  <guideline key="Ch01_7565e63" severity="DO" section="Coding" subsection="Miscellaneous">"DO capitalize only the first character in acronyms with three or more characters, except for the first word of a camelCased identifier."</guideline>
  <guideline key="Ch01_5fbe0b8" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT capitalize any of the characters in acronyms at the beginning of a camelCased identifier.</guideline>
  <guideline key="Ch12_eb8a1e1" severity="DO" section="Coding" subsection="Miscellaneous">DO choose meaningful names for type parameters and prefix the name with T.</guideline>
  <guideline key="Ch10_57b5bd2" severity="DO NOT" section="Coding" subsection="Miscellaneous">DO NOT define types without placing them into a namespace.</guideline>
  <guideline key="Ch12_6f21a67" severity="CONSIDER" section="Coding" subsection="Miscellaneous">CONSIDER indicating a constraint in the name of a type parameter.</guideline>
  <guideline key="Ch01_73d80ae" severity="DO" section="Coding" subsection="Miscellaneous">DO favor clarity over brevity when naming identifiers.</guideline>
  <guideline key="Ch02_e712b97" severity="DO" section="Coding" subsection="Miscellaneous">"DO use uppercase literal suffixes (e.g., 1.618033988749895M)."</guideline>
  <guideline key="Ch03_5b13443" severity="CONSIDER" section="Coding" subsection="Miscellaneous">CONSIDER using PascalCasing for all tuple item names.</guideline>
  <guideline key="Ch03_684e2db" severity="DO" section="Coding" subsection="Miscellaneous">DO use camelCasing for variable declarations using tuple syntax. </guideline>
  <guideline key="Ch01_026c169" severity="DO" section="Coding" subsection="Miscellaneous">DO use camelCasing for local variable names.</guideline>
  <guideline key="Ch05_76e42bd" severity="DO" section="Coding" subsection="Miscellaneous">DO use camelCasing for parameter names.</guideline>
  <guideline key="Ch05_d2ad07e" severity="DO" section="Coding" subsection="Namespaces">DO use PascalCasing for namespace names.</guideline>
  <guideline key="Ch10_43776b8" severity="DO" section="Coding" subsection="Namespaces">DO prefix namespace names with a company name to prevent namespaces from different companies having the same name.</guideline>
  <guideline key="Ch10_cfd2d4a" severity="DO" section="Coding" subsection="Namespaces">"DO use a stable, version-independent product name at the second level of a namespace name."</guideline>
  <guideline key="Ch06_7f9df1d" severity="DO" section="Coding" subsection="Parameters">DO provide constructor optional parameters and/or convenience constructor overloads that initialize properties with good defaults.</guideline>
  <guideline key="Ch05_75ff283" severity="DO" section="Coding" subsection="Parameters">DO provide simple method overloads that have a small number of required parameters.</guideline>
  <guideline key="Ch18_fb6c80d" severity="AVOID" section="Coding" subsection="Parameters">"AVOID providing constructor parameters to initialize attribute properties corresponding to the optional arguments (and, therefore, avoid overloading custom attribute constructors)."</guideline>
  <guideline key="Ch23_4c7fa17" severity="DO" section="Coding" subsection="Parameters">DO simplify the wrapper methods by choosing default values for unnecessary parameters.</guideline>
  <guideline key="Ch05_f5f97f1" severity="CONSIDER" section="Coding" subsection="Parameters">CONSIDER organizing overloads from the simplest to the most complex.</guideline>
  <guideline key="Ch05_02450bc" severity="DO" section="Coding" subsection="Parameters">DO provide good defaults for all parameters where possible.</guideline>
  <guideline key="Ch06_995dfaa" severity="DO" section="Coding" subsection="Properties">DO use properties for simple access to simple data with simple computations.</guideline>
  <guideline key="Ch06_e2d10a1" severity="DO" section="Coding" subsection="Properties">DO favor automatically implemented properties over properties with simple backing fields when no additional logic is required.</guideline>
  <guideline key="Ch06_6667185" severity="CONSIDER" section="Coding" subsection="Properties">"CONSIDER using the same casing on a property’s backing field as that used in the property, distinguishing the backing field with an “_” prefix. Do not, however, use two underscores; identifiers beginning with two underscores are reserved for the use of t"</guideline>
  <guideline key="Ch06_dc89394" severity="DO" section="Coding" subsection="Properties">"DO use nameof(value) (which resolves to “value”) for the paramName argument when creating ArgumentException() or ArgumentNullException() type exceptions (value"" is the implicit name of the parameter on property setters)."""</guideline>
  <guideline key="Ch06_2e0ebdb" severity="DO" section="Coding" subsection="Properties">DO favor automatically implemented properties over fields.</guideline>
  <guideline key="Ch06_7e076a4" severity="DO" section="Coding" subsection="Properties">DO favor automatically implemented properties over using fully expanded ones if there is no additional implementation logic.</guideline>
  <guideline key="Ch06_26d0d4d" severity="AVOID" section="Coding" subsection="Properties">"AVOID accessing the backing field of a property outside the property, even from within the containing class."</guideline>
  <guideline key="Ch06_6189514" severity="DO" section="Coding" subsection="Properties">DO create read-only properties if the property value should not be changed.</guideline>
  <guideline key="Ch06_816174c" severity="DO" section="Coding" subsection="Properties">DO create read-only automatically implemented properties in C# 6.0 (or later) rather than read-only properties with a backing field if the property value should not be changed.</guideline>
  <guideline key="Ch06_7dda59f" severity="CONSIDER" section="Coding" subsection="Properties">CONSIDER giving a property the same name as its type.</guideline>
  <guideline key="Ch06_ebb074f" severity="DO" section="Coding" subsection="Properties">DO apply appropriate accessibility modifiers on implementations of getters and setters on all properties.</guideline>
  <guideline key="Ch06_d814e9a" severity="DO NOT" section="Coding" subsection="Properties">DO NOT provide set-only properties or properties with the setter having broader accessibility than the getter.</guideline>
  <guideline key="Ch06_028c753" severity="DO" section="Coding" subsection="Properties">"DO favor prefixing Boolean properties with “Is,” “Can,” or “Has,” when that practice adds value."</guideline>
  <guideline key="Ch06_2fa1861" severity="DO" section="Coding" subsection="Properties">"DO name properties using a noun, noun phrase, or adjective."</guideline>
  <guideline key="Ch06_e6aad81" severity="DO" section="Coding" subsection="Properties">"DO provide sensible defaults for all properties, ensuring that defaults do not result in a security hole or significantly inefficient code."</guideline>
  <guideline key="Ch06_0d3a13f" severity="DO" section="Coding" subsection="Properties">DO name properties with PascalCase.</guideline>
  <guideline key="Ch06_f455cdc" severity="DO" section="Coding" subsection="Properties">"DO allow properties to be set in any order, even if this results in a temporarily invalid object state."</guideline>
  <guideline key="Ch06_50d676e" severity="DO" section="Coding" subsection="Properties">DO favor read-only automatically implemented properties in C# 6.0 (or later) over read-only fields.</guideline>
  <guideline key="Ch06_a1eeb77" severity="DO" section="Coding" subsection="Properties">DO use a nullable check for all reference-type properties and fields that are not initialized before instantiation completes.</guideline>
  <guideline key="Ch06_95f0537" severity="DO" section="Coding" subsection="Properties">DO implement non-nullable reference-type automatically implemented properties as read-only.</guideline>
  <guideline key="Ch06_b85aa4e" severity="DO" section="Coding" subsection="Properties">DO assign non-nullable reference-type properties before instantiation completes.</guideline>
  <guideline key="Ch06_759b766" severity="DO" section="Coding" subsection="Properties">"DO implement non-nullable read/write reference fully implemented properties with a nullable backing field, a null-forgiveness operator when returning the field from the getter, and non-null validation in the property setter."</guideline>
  <guideline key="Ch04_2dc14f6" severity="DO" section="Coding" subsection="Strings">DO favor composite formatting over use of the addition operator for concatenating strings when localization is a possibility.</guideline>
  <guideline key="Ch09_6d059d3" severity="DO NOT" section="Coding" subsection="Structs">"DO NOT define a struct unless it logically represents a single value, consumes 16 bytes or less of storage, is immutable, and is infrequently boxed."</guideline>
  <guideline key="Ch09_be07b3a" severity="DO" section="Coding" subsection="Structs">DO ensure that the default value of a struct is valid; encapsulation cannot prevent obtaining the default “all zero” value of a struct.</guideline>
  <guideline key="Ch22_14c2494" severity="AVOID" section="Coding" subsection="Synchronization">"AVOID synchronization on simple reading or writing of values no bigger than a native (pointer-size) integer, as such operations are automatically atomic."</guideline>
  <guideline key="Ch22_52cbe24" severity="DO" section="Coding" subsection="Synchronization">DO encapsulate mutable static data in public APIs with synchronization logic.</guideline>
  <guideline key="Ch22_13460e8" severity="DO NOT" section="Coding" subsection="Synchronization">DO NOT request exclusive ownership of the same two or more synchronization targets in different orders.</guideline>
  <guideline key="Ch22_b7b568a" severity="AVOID" section="Coding" subsection="Synchronization">AVOID using the MethodImplAttribute for synchronization.</guideline>
  <guideline key="Ch22_a42b43f" severity="DO" section="Coding" subsection="Synchronization">"DO declare a separate, read-only synchronization variable of type object for the synchronization target."</guideline>
  <guideline key="Ch19_be97c7f" severity="DO" section="Coding" subsection="Tasks">DO cancel unfinished tasks rather than allowing them to run during application shutdown.</guideline>
  <guideline key="Ch19_2d01ebf" severity="DO" section="Coding" subsection="Tasks">DO cancel unfinished tasks rather than allowing them to run during application shutdown.</guideline>
  <guideline key="Ch19_6354f56" severity="DO" section="Coding" subsection="Tasks">DO inform the task factory that a newly created task is likely to be long-running so that it can manage it appropriately.</guideline>
  <guideline key="Ch19_ab37043" severity="DO" section="Coding" subsection="Tasks">DO use tasks and related APIs in favor of System.Theading classes such as Thread and ThreadPool.</guideline>
  <guideline key="Ch19_0938a54" severity="DO" section="Coding" subsection="Tasks">DO use TaskCreationOptions.LongRunning sparingly.</guideline>
  <guideline key="Ch19_870ca4e" severity="AVOID" section="Coding" subsection="Threads">AVOID writing programs that produce unhandled exceptions on any thread.</guideline>
  <guideline key="Ch19_7d3d706" severity="DO NOT" section="Coding" subsection="Threads">DO NOT assume that all threads will observe all side effects of operations on shared memory in a consistent order.</guideline>
  <guideline key="Ch19_ad20608" severity="AVOID" section="Coding" subsection="Threads">AVOID calling Thread.Sleep() in production code.</guideline>
  <guideline key="Ch19_f673b58" severity="DO" section="Coding" subsection="Threads">DO carefully measure performance when attempting to speed up processor-bound problems through multithreading.</guideline>
  <guideline key="Ch21_4e5cdcb" severity="DO" section="Coding" subsection="Threads">DO use parallel loops when the computations performed can be easily split up into many mutually independent processor-bound computations that can be executed in any order on any thread.</guideline>
  <guideline key="Ch22_0cfbbd3" severity="AVOID" section="Coding" subsection="Threads">"AVOID locking on this, System.Type, or a string."</guideline>
  <guideline key="Ch19_80bf717" severity="DO" section="Coding" subsection="Threads">DO ensure that code that concurrently acquires multiple locks always acquires them in the same order.</guideline>
  <guideline key="Ch19_67c766c" severity="DO NOT" section="Coding" subsection="Threads">DO NOT fall into the common error of believing that more threads always make code faster.</guideline>
  <guideline key="Ch22_025dd17" severity="DO" section="Coding" subsection="Threads">DO ensure that code that concurrently holds multiple locks always acquires them in the same order.</guideline>
  <guideline key="Ch19_86467fb" severity="DO NOT" section="Coding" subsection="Threads">DO NOT make an unwarranted assumption that any operation that is seemingly atomic in single-threaded code will be atomic in multithreaded code.</guideline>
  <guideline key="Ch19_9bb06a2" severity="AVOID" section="Coding" subsection="Threads">"AVOID all race conditions—that is, conditions where program behavior depends on how the operating system chooses to schedule threads."</guideline>
  <guideline key="Ch10_b4181c3" severity="CONSIDER" section="Coding" subsection="ToString()">CONSIDER returning a unique string from ToString() so as to identify the object instance.</guideline>
  <guideline key="Ch10_28c8bdc" severity="DO" section="Coding" subsection="ToString()">"DO provide an overloaded ToString(string format) or implement IFormattable if the return value requires formatting or is culture-sensitive (e.g., DateTime)."</guideline>
  <guideline key="Ch10_357ce81" severity="DO" section="Coding" subsection="ToString()">DO override ToString() whenever useful developer-oriented diagnostic strings can be returned.</guideline>
  <guideline key="Ch10_c8a5c88" severity="CONSIDER" section="Coding" subsection="ToString()">CONSIDER trying to keep the string returned from ToString() short.</guideline>
  <guideline key="Ch10_e4df230" severity="DO NOT" section="Coding" subsection="ToString()">DO NOT return an empty string or null from ToString().</guideline>
  <guideline key="Ch10_b682bd8" severity="DO NOT" section="Coding" subsection="ToString()">DO NOT throw exceptions or make observable side effects (change the object state) from ToString().</guideline>
  <guideline key="Ch09_b801200" severity="AVOID" section="Coding" subsection="Types">AVOID creating value types that consume more than 16 bytes of memory.</guideline>
  <guideline key="Ch09_33f3905" severity="DO" section="Coding" subsection="Types">DO make value types immutable.</guideline>
  <guideline key="Ch09_c8e14e3" severity="AVOID" section="Coding" subsection="Types">AVOID mutable value types.</guideline>
  <guideline key="Ch04_8a3d463" severity="AVOID" section="Coding" subsection="Types">"AVOID using equality conditionals with binary floating-point types. Either subtract the two values and see if their difference is less than a tolerance, or  use the decimal type."</guideline>
  <guideline key="Ch04_76b0471" severity="AVOID" section="Coding" subsection="Types">AVOID binary floating-point types when exact decimal arithmetic is required; use the decimal floating-point type instead.</guideline>
  <guideline key="Ch14_9fbba33" severity="CONSIDER" section="Coding" subsection="Types">CONSIDER using a subclass of System.EventArgs as the event argument type (TEventArgs) unless you are sure the event will never need to carry any data.</guideline>
  <guideline key="Ch12_c532a51" severity="AVOID" section="Coding" subsection="Types">AVOID implementing multiple constructions of the same generic interface in one type.</guideline>
  <guideline key="Ch13_6ae7a90" severity="CONSIDER" section="Coding" subsection="Types">CONSIDER whether the readability benefit of defining your own delegate type outweighs the convenience of using a predefined generic delegate type.</guideline>
  <guideline key="Ch13_ab0aca8" severity="CONSIDER" section="Coding" subsection="Types">CONSIDER omitting the types from lambda formal parameter lists when the types are obvious to the reader or when they are an insignificant detail.</guideline>
  <guideline key="Ch14_6baa967" severity="DO" section="Coding" subsection="Types">DO use System.EventArgs or a type that derives from System.EventArgs for a TEventArgs type.</guideline>
  <guideline key="Ch03_f566c99" severity="AVOID" section="Coding" subsection="Types">AVOID using implicitly typed local variables unless the data type of the assigned value is obvious.</guideline>
  <guideline key="Ch14_3e1089d" severity="CONSIDER" section="Coding" subsection="Types">CONSIDER using System.EventHandler&lt;T&gt; instead of manually creating new delegate types for event handlers unless the parameter names of a custom type offer significant clarification.</guideline>
  <guideline severity="CONSIDER" section="Coding" subsection="Variables">CONSIDER using var any time that the initialization of the variable clearly shows what the variable will contain.</guideline>
  <guideline severity="CONSIDER" section="Coding" subsection="Variables">CONSIDER using target-typed new expressions any time that the instance clearly shows its type.</guideline>
  <guideline key="Ch04_9fa9f67" severity="AVOID" section="Coding" subsection="Whitespace">"AVOID omitting braces, except for the simplest of single-line if statements."</guideline>
  <guideline key="Ch04_19bd2d2" severity="DO" section="Coding" subsection="Whitespace">"DO use parentheses to make code more readable, particularly if the operator precedence is not clear to the casual reader."</guideline>
</Guidelines>