Update Configuration documentation to clarify kind and accessibility orderings

Author: sharwell

documentation/Configuration.md

@@ -96,8 +96,9 @@ and SA1215) evaluate these traits in the order they are defined to identify orde
 this property when reordering code elements. Any traits which are omitted from the array are ignored. The following
 traits are supported:
 
-* `kind`: Elements are ordered according to their kind
-* `accessibility`: Elements are ordered according to their declared accessibility
+* `kind`: Elements are ordered according to their kind (see [SA1201](SA1201.md) for this predefined order)
+* `accessibility`: Elements are ordered according to their declared accessibility (see [SA1202](SA1202.md) for this
+  predefined order)
 * `constant`: Constant elements are ordered before non-constant elements
 * `static`: Static elements are ordered before non-static elements
 * `readonly`: Readonly elements are ordered before non-readonly elements

documentation/SA1201.md

@@ -25,51 +25,29 @@ A violation of this rule occurs when the code elements within a file do not foll
 
 To comply with this rule, elements at the file root level or within a namespace must be positioned in the following order:
 
-*Extern Alias Directives*
-
-*Using Directives*
-
-*Namespaces*
-
-*Delegates*
-
-*Enums*
-
-*Interfaces*
-
-*Structs*
-
-*Classes*
-
-
+* Extern Alias Directives
+* Using Directives
+* Namespaces
+* Delegates
+* Enums
+* Interfaces
+* Structs
+* Classes
 
 Within a class, struct, or interface, elements must be positioned in the following order:
 
-*Fields*
-
-*Constructors*
-
-*Finalizers (Destructors)*
-
-*Delegates*
-
-*Events*
-
-*Enums*
-
-*Interfaces*
-
-*Properties*
-
-*Indexers*
-
-*Methods*
-
-*Structs*
-
-*Classes*
-
-
+* Fields
+* Constructors
+* Finalizers (Destructors)
+* Delegates
+* Events
+* Enums
+* Interfaces
+* Properties
+* Indexers
+* Methods
+* Structs
+* Classes*
 
 Complying with a standard ordering scheme based on element type can increase the readability and maintainability of the file and encourage code reuse.
 

documentation/SA1202.md

@@ -17,27 +17,27 @@
 
 ## Cause
 
-An element within a C# code file is out of order within regard to access level, in relation to other elements in the code.
+An element within a C# code file is out of order within regard to access level, in relation to other elements in the
+code.
 
 ## Rule description
 
-A violation of this rule occurs when the code elements within a file do not follow a standard ordering scheme based on access level.
+A violation of this rule occurs when the code elements within a file do not follow a standard ordering scheme based on
+access level.
 
 To comply with this rule, adjacent elements of the same type must be positioned in the following order by access level:
 
-*public*
+* public
+* internal
+* protected internal
+* protected
+* private
 
-*internal*
+:memo: Static constructors and explicitly implemented interface members are considered *public* for the purposes of this
+rule.
 
-*protected internal*
-
-*protected*
-
-*private*
-
-
-
-Complying with a standard ordering scheme based on access level can increase the readability and maintainability of the file and make it easier to identify the public interface that is being exposed from a class.
+Complying with a standard ordering scheme based on access level can increase the readability and maintainability of the
+file and make it easier to identify the public interface that is being exposed from a class.
 
 ## How to fix violations