Fix indentation, quotes, and code blocks

documentation/SA1003.md

@@ -24,17 +24,24 @@ The spacing around an operator symbol is incorrect, within a C# code file.
 A violation of this rule occurs when the spacing around an operator symbol is incorrect.
 
 The following types of operator symbols must be surrounded by a single space on either side: colons, arithmetic operators, assignment operators, conditional operators, logical operators, relational operators, shift operators, and lambda operators. For example:
-    int x = 4 + y;
-In contrast, unary operators must be preceded by a single space, but must never be followed by any space. For example:
-    bool x = !value;
-
-An exception occurs whenever the symbol is preceded or followed by a parenthesis or bracket, in which case there should be no space between the symbol and the bracket. For example:
-
-    if (!value)
-    {
-    }
 
+```csharp
+int x = 4 + y;
+```
+
+In contrast, unary operators must be preceded by a single space, but must never be followed by any space. For example:
 
+```csharp
+bool x = !value;
+```
+
+An exception occurs whenever the symbol is preceded or followed by a parenthesis or bracket, in which case there should be no space between the symbol and the bracket. For example:
+
+```csharp
+if (!value)
+{
+}
+```
 
 ## How to Fix Violations
 

documentation/SA1004.md

@@ -20,27 +20,32 @@
 A line within a documentation header above a C# element does not begin with a single space.
 
 ## Rule Description
+
 A violation of this rule occurs when a line within a documentation header does not begin with a single space. For example:
-    ///<summary>
-    ///The summary text.
-    ///</summary>
-    ///   <param name="x">The document root.</param>
-    ///    <param name="y">The Xml header token.</param>
-    private void Method1(int x, int y)
-    {
-    }
-
-The header lines should begin with a single space after the three leading forward slashes:
-    /// <summary>
-    /// The summary text.
-    /// </summary>
-    /// <param name="x">The document root.</param>
-    /// <param name="y">The Xml header token.</param>
-    private void Method1(int x, int y)
-    {
-    }
 
+```csharp
+///<summary>
+///The summary text.
+///</summary>
+///   <param name="x">The document root.</param>
+///    <param name="y">The Xml header token.</param>
+private void Method1(int x, int y)
+{
+}
+```
+
+The header lines should begin with a single space after the three leading forward slashes:
 
+```csharp
+/// <summary>
+/// The summary text.
+/// </summary>
+/// <param name="x">The document root.</param>
+/// <param name="y">The Xml header token.</param>
+private void Method1(int x, int y)
+{
+}
+```
 
 ## How to Fix Violations
 

documentation/SA1005.md

@@ -22,26 +22,34 @@ A single-line comment within a C# code file does not begin with a single space.
 ## Rule Description
 
 A violation of this rule occurs when a single-line comment does not begin with a single space. For example:
-    private void Method1()
-    {
-        //A single-line comment.
-        //   A single-line comment.
-    }
-
+
+```csharp
+private void Method1()
+{
+    //A single-line comment.
+    //   A single-line comment.
+}
+```
+
 The comments should begin with a single space after the leading forward slashes:
-    private void Method1()
-    {
-        // A single-line comment.
-        // A single-line comment.
-    }
-
+
+```csharp
+private void Method1()
+{
+    // A single-line comment.
+    // A single-line comment.
+}
+```
+
 An exception to this rule occurs when the comment is being used to comment out a line of code. In this case, the space can be omitted if the comment begins with four forward slashes to indicate out-commented code. For example:
-    private void Method1()
-    {
-        ////int x = 2;
-        ////return x;
-    }
-
+
+```csharp
+private void Method1()
+{
+    ////int x = 2;
+    ////return x;
+}
+```
 
 ## How to Fix Violations
 

documentation/SA1006.md

@@ -22,9 +22,16 @@ A C# preprocessor-type keyword is preceded by space.
 ## Rule Description
 
 A violation of this rule occurs when the preprocessor-type keyword in a preprocessor directive is preceded by space. For example:
-    # if Debug
+
+```csharp
+# if Debug
+```
+
 There should not be any whitespace between the opening hash mark and the preprocessor-type keyword:
-    #if Debug
+
+```csharp
+#if Debug
+```
 
 ## How to Fix Violations
 

documentation/SA1007.md

@@ -22,11 +22,12 @@ The operator keyword within a C# operator overload method is not followed by any
 ## Rule Description
 
 A violation of this rule occurs when the operator keyword within an operator overload method is not followed by any whitespace. The operator keyword should always be followed by a single space. For example:
-    public MyClass operator +(MyClass a, MyClass b)
-    {
-    }
-
 
+```csharp
+public MyClass operator +(MyClass a, MyClass b)
+{
+}
+```
 
 ## How to Fix Violations
 

documentation/SA1011.md

@@ -25,7 +25,7 @@ A violation of this rule occurs when the spacing around a closing square bracket
 
 A closing square bracket must never be preceded by whitespace, unless it is the first character on the line.
 
-A closing square bracket must be followed by whitespace, unless it is the last character on the line, it is followed by a closing bracket or an opening parenthesis, it is followed by a comma or semicolon, or it is followed by certain types of operator symbols.
+A closing square bracket must be followed by whitespace, unless it is the last character on the line, it is followed by a closing bracket or an opening parenthesis, it is followed by a comma or semicolon, or it is followed by certain types of operator symbols.
 
 ## How to Fix Violations
 

documentation/SA1023.md

@@ -24,14 +24,16 @@ A dereference symbol or an access-of symbol within a C# element is not spaced co
 A violation of this rule occurs when the spacing around a dereference or access-of symbol is not correct.
 
 The spacing around the symbol depends upon whether the symbol is used within a type declaration. If so, the symbol must always be followed by a single space, unless it is the last character on the line, or is followed by an opening square bracket or a parenthesis. In addition, the symbol should not be preceded by whitespace, and should not be the first character on the line. An example of a properly spaced dereference symbol used within a type declaration is:
-    object* x = null;
-
-When a dereference or access-of symbol is used outside of a type declaration, the 
-    opposite rule applies. In this case, the symbol must always be preceded by a 
-    single space, unless it is the first character on the line, or is preceded by an 
-    opening square bracket, a parenthesis or a symbol of the same type i.e. an 
-    equals. The symbol should not be followed by whitespace, and should not be the last character on the line. For example:
-    y = *x;
+
+```csharp
+object* x = null;
+```
+
+When a dereference or access-of symbol is used outside of a type declaration, the opposite rule applies. In this case, the symbol must always be preceded by a single space, unless it is the first character on the line, or is preceded by an opening square bracket, a parenthesis or a symbol of the same type i.e. an equals. The symbol should not be followed by whitespace, and should not be the last character on the line. For example:
+
+```csharp
+y = *x;
+```
 
 ## How to Fix Violations
 

documentation/SA1024.md

@@ -24,29 +24,32 @@ A colon within a C# element is not spaced correctly.
 A violation of this rule occurs when the spacing around a colon is not correct.
 
 The spacing around a colon depends upon the type of colon and how it is used within the code. A colon appearing within an element declaration must always have a single space on either side, unless it is the first or last character on the line. For example all of the colons below follow this rule:
-    public class Class2<T> : Class1 where T : MyType
-    {
-        public Class2(int x) : base(x)
-        {
-        }
-    }
-
 
+```csharp
+public class Class2<T> : Class1 where T : MyType
+{
+    public Class2(int x) : base(x)
+    {
+    }
+}
+```
 
 When the colon comes at the end of a label or case statement, it must always be followed by whitespace or be the last character on the line, but should never be preceded by whitespace. For example:
-    _label:
-    switch (x)
-    {
-        case 2: 
-            return x;
-    }
-
 
+```csharp
+_label:
+switch (x)
+{
+    case 2: 
+        return x;
+}
+```
 
 Finally, when a colon is used within a conditional statement, it must always contain a single space on either side, unless the colon is the first or last character on the line. For example:
-    int x = y ? 2 : 3;
-
 
+```csharp
+int x = y ? 2 : 3;
+```
 
 ## How to Fix Violations
 

documentation/SA1027.md

@@ -23,7 +23,7 @@ The C# code contains a tab character.
 
 A violation of this rule occurs whenever the code contains a tab character.
 
-Tabs should not be used within C# code, because the length of the tab character can vary depending upon the editor being used to view the code. This can cause the spacing and indexing of the code to vary from the developer’s original intention, and can in some cases make the code difficult to read.
+Tabs should not be used within C# code, because the length of the tab character can vary depending upon the editor being used to view the code. This can cause the spacing and indexing of the code to vary from the developer's original intention, and can in some cases make the code difficult to read.
 
 For these reasons, tabs should not be used, and each level of indentation should consist of four spaces. This will ensure that the code looks the same no matter which editor is being used to view the code.
 

documentation/SA1100.md

@@ -17,33 +17,40 @@
 
 ## Cause
 
-A call to a member from an inherited class begins with ‘base.’, and the local class does not contain an override or implementation of the member.
+A call to a member from an inherited class begins with `base.`, and the local class does not contain an override or implementation of the member.
 
 ## Rule Description
 
-A violation of this rule occurs whenever the code contains a call to a member from the base class prefixed with ‘base.’, and there is no local implementation of the member. For example:
-    string name = base.JoinName("John", "Doe");
+A violation of this rule occurs whenever the code contains a call to a member from the base class prefixed with `base.`, and there is no local implementation of the member. For example:
+
+```csharp
+string name = base.JoinName("John", "Doe");
+```
 
 This rule is in place to prevent a potential source of bugs. Consider a base class which contains the following virtual method:
-    public virtual string JoinName(string first, string last)
-    {
-    }
-
 
-Another class inherits from this base class but does not provide a local override of this method. Somewhere within this class, the base class method is called using base.JoinName(...). This works as expected. At a later date, someone adds a local override of this method to the class:
-    public override string JoinName(string first, string last)
-    {
-        return “Bob”;
-    }
-
+```csharp
+public virtual string JoinName(string first, string last)
+{
+}
+```
+
+Another class inherits from this base class but does not provide a local override of this method. Somewhere within this class, the base class method is called using `base.JoinName(...)`. This works as expected. At a later date, someone adds a local override of this method to the class:
+
+```csharp
+public override string JoinName(string first, string last)
+{
+    return "Bob";
+}
+```
 
-At this point, the local call to base.JoinName(...) most likely introduces a bug into the code. This call will always call the base class method and will cause the local override to be ignored. 
+At this point, the local call to `base.JoinName(...)` most likely introduces a bug into the code. This call will always call the base class method and will cause the local override to be ignored. 
 
-For this reason, calls to members from a base class should not begin with ‘base.’, unless a local override is implemented, and the developer wants to specifically call the base class member. When there is no local override of the base class member, the call should be prefixed with 'this.' rather than 'base.'.
+For this reason, calls to members from a base class should not begin with `base.`, unless a local override is implemented, and the developer wants to specifically call the base class member. When there is no local override of the base class member, the call should be prefixed with `this.` rather than `base.`.
 
 ## How to Fix Violations
 
-To fix a violation of this rule, change the ‘base.’ prefix to ‘this.’.
+To fix a violation of this rule, change the `base.` prefix to `this.`.
 
 ## How to Suppress Violations
 

documentation/SA1101.md

@@ -17,19 +17,19 @@
 
 ## Cause
 
-A call to an instance member of the local class or a base class is not prefixed with ‘this.’, within a C# code file.
+A call to an instance member of the local class or a base class is not prefixed with 'this.', within a C# code file.
 
 ## Rule Description
 
-A violation of this rule occurs whenever the code contains a call to an instance member of the local class or a base class which is not prefixed with ‘this.’. An exception to this rule occurs when there is a local override of a base class member, and the code intends to call the base class member directly, bypassing the local override. In this case the call can be prefixed with ‘base.’ rather than ‘this.’.
+A violation of this rule occurs whenever the code contains a call to an instance member of the local class or a base class which is not prefixed with 'this.'. An exception to this rule occurs when there is a local override of a base class member, and the code intends to call the base class member directly, bypassing the local override. In this case the call can be prefixed with 'base.' rather than 'this.'.
 
-By default, StyleCop disallows the use of underscores or *m_* to mark local class fields, in favor of the ‘this.’ prefix. The advantage of using ‘this.’ is that it applies equally to all element types including methods, properties, etc., and not just fields, making all calls to class members instantly recognizable, regardless of which editor is being used to view the code. Another advantage is that it creates a quick, recognizable differentiation between instance members and static members, which are not be prefixed.
+By default, StyleCop disallows the use of underscores or *m_* to mark local class fields, in favor of the 'this.' prefix. The advantage of using 'this.' is that it applies equally to all element types including methods, properties, etc., and not just fields, making all calls to class members instantly recognizable, regardless of which editor is being used to view the code. Another advantage is that it creates a quick, recognizable differentiation between instance members and static members, which are not be prefixed.
 
-A final advantage of using the ‘this.’ prefix is that typing *this.* will cause Visual Studio to show the IntelliSense popup, making it quick and easy for the developer to choose the class member to call.
+A final advantage of using the 'this.' prefix is that typing *this.* will cause Visual Studio to show the IntelliSense popup, making it quick and easy for the developer to choose the class member to call.
 
 ## How to Fix Violations
 
-To fix a violation of this rule, insert the ‘this.’ prefix before the call to the class member.
+To fix a violation of this rule, insert the 'this.' prefix before the call to the class member.
 
 ## How to Suppress Violations