Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add in field naming convention updates #143

Merged
merged 2 commits into from
Feb 17, 2021
Merged

Add in field naming convention updates #143

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
961c130
Add in field naming convention updates
BenjaminMichaelis Feb 12, 2021
102be59
Update docs/Guidelines(8th Edition).xml
Keboo Feb 17, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions docs/Guidelines(8th Edition).xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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="Ch06_d75e3ef" severity="DO" section="Naming" subsection="Casing">Name fields with PascalCase and a leading underscore.</guideline>
Keboo marked this conversation as resolved.
Show resolved Hide resolved
<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>
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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>