Add in field naming convention updates (#143)

* Add in field naming convention updates

Add in field naming convention updates to match ReadMe Design Guidelines for clarity.

* Update docs/Guidelines(8th Edition).xml

Co-authored-by: Kevin B <Keboo@users.noreply.github.com>

docs/Guidelines(8th Edition).xml

@@ -64,6 +64,7 @@
 	<guideline key="Ch06_2fa1861" severity="DO" section="Naming" subsection="Variables and fields">"DO name properties using a noun, noun phrase, or adjective."</guideline>
 	<guideline key="Ch06_7dda59f" severity="CONSIDER" section="Naming" subsection="Miscellaneous">CONSIDER giving a property the same name as its type.</guideline>
 	<guideline key="Ch06_d75e3ef" severity="AVOID" section="Naming" subsection="Casing">AVOID naming fields with camelCase.</guideline>
+        <guideline key="" severity="DO" section="Naming" subsection="Variables and fields">Name fields with PascalCase and a leading underscore.</guideline>
 	<guideline key="Ch06_028c753" severity="DO" section="Naming" subsection="Casing">"DO favor prefixing Boolean properties with “Is,” “Can,” or “Has,” when that practice adds value."</guideline>
 	<guideline key="Ch06_d80065c" severity="DO" section="Naming" subsection="Variables and fields">DO declare all instance fields as private (and expose them via a property).</guideline>
 	<guideline key="Ch06_0d3a13f" severity="DO" section="Naming" subsection="Casing">DO name properties with PascalCase.</guideline>
@@ -92,7 +93,7 @@
 	<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 an “I” prefix for interface names.</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="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_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="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>
@@ -247,4 +248,4 @@
 	<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="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="Ch23_d560942" severity="DO" section="Coding" subsection="Miscellaneous">DO use ref parameters rather than pointer types when possible.</guideline>
-</Guidelines>
+</Guidelines>