Fix multiple formatting errors

DotNetAnalyzers · Aug 24, 2015 · f8899a9 · f8899a9
1 parent b51b274
commit f8899a9
Show file tree

Hide file tree

Showing 7 changed files with 44 additions and 108 deletions.
diff --git a/documentation/SA1121.md b/documentation/SA1121.md
@@ -29,89 +29,23 @@ Rather than using the type name or the fully-qualified type name, the built-in a
 
 The following table lists each of these types in all three formats:
 
-<table>
-  <tr>
-    <td>**Type Alias**</td>
-    <td>**Type**</td>
-    <td>**Fully Qualified Type**</td>
-  </tr>
-  <tr>
-    <td>bool</td>
-    <td>Boolean</td>
-    <td>System.Boolean</td>
-  </tr>
-  <tr>
-    <td>byte</td>
-    <td>Byte</td>
-    <td>System.Byte</td>
-  </tr>
-  <tr>
-    <td>char</td>
-    <td>Char</td>
-    <td>System.Char</td>
-  </tr>
-  <tr>
-    <td>decimal</td>
-    <td>Decimal</td>
-    <td>System.Decimal</td>
-  </tr>
-  <tr>
-    <td>double</td>
-    <td>Double</td>
-    <td>System.Double</td>
-  </tr>
-  <tr>
-    <td>short</td>
-    <td>Int16</td>
-    <td>System.Int16</td>
-  </tr>
-  <tr>
-    <td>int</td>
-    <td>Int32</td>
-    <td>System.Int32</td>
-  </tr>
-  <tr>
-    <td>long</td>
-    <td>Int64</td>
-    <td>System.Int64</td>
-  </tr>
-  <tr>
-    <td>object</td>
-    <td>Object</td>
-    <td>System.Object</td>
-  </tr>
-  <tr>
-    <td>sbyte</td>
-    <td>SByte</td>
-    <td>System.SByte</td>
-  </tr>
-  <tr>
-    <td>float</td>
-    <td>Single</td>
-    <td>System.Single</td>
-  </tr>
-  <tr>
-    <td>string</td>
-    <td>String</td>
-    <td>System.String</td>
-  </tr>
-  <tr>
-    <td>ushort</td>
-    <td>UInt16</td>
-    <td>System.UInt16</td>
-  </tr>
-  <tr>
-    <td>uint</td>
-    <td>UInt32</td>
-    <td>System.UInt32</td>
-  </tr>
-  <tr>
-    <td>ulong</td>
-    <td>UInt64</td>
-    <td>System.UInt64</td>
-  </tr>
-</table>
-
+| Type Alias | Type | Fully Qualified Type |
+| --- | --- | --- |
+| bool | Boolean | System.Boolean |
+| byte | Byte | System.Byte |
+| char | Char | System.Char |
+| decimal | Decimal | System.Decimal |
+| double | Double | System.Double |
+| short | Int16 | System.Int16 |
+| int | Int32 | System.Int32 |
+| long | Int64 | System.Int64 |
+| object | Object | System.Object |
+| sbyte | SByte | System.SByte |
+| float | Single | System.Single |
+| string | String | System.String |
+| ushort | UInt16 | System.UInt16 |
+| uint | UInt32 | System.UInt32 |
+| ulong | UInt64 | System.UInt64 |
 
 ## How to Fix Violations
 

diff --git a/documentation/SA1125.md b/documentation/SA1125.md
@@ -17,7 +17,7 @@
 
 ## Cause
 
-The Nullable type has been defined not using the C# shorthand. For example, Nullable<DateTime> has been used instead of the preferred DateTime?
+The Nullable type has been defined not using the C# shorthand. For example, `Nullable<DateTime>` has been used instead of the preferred `DateTime?`
 
 ## Rule Description
 

diff --git a/documentation/SA1200.md b/documentation/SA1200.md
@@ -59,7 +59,7 @@ There are subtle differences between placing using directives within a namespace
 
 ### 1. Eliminating Type Confusion
 
-Consider the following code, which contains a using-alias directive defined outside of the namespace element. The code creates a new class called *Guid*, and also defines a using-alias directive to map the name *Guid *to the type *System.Guid. *Finally, the code creates an instance of the type *Guid*:
+Consider the following code, which contains a using-alias directive defined outside of the namespace element. The code creates a new class called *Guid*, and also defines a using-alias directive to map the name *Guid* to the type *System.Guid*. Finally, the code creates an instance of the type *Guid*:
 
 ```csharp
 using Guid = System.Guid;
@@ -112,13 +112,17 @@ The code fails on the following compiler error, found on the line containing `Gu
 > CS0576: Namespace 'Microsoft.Sample' contains a definition conflicting with alias 'Guid'
 
 The code creates an alias to the *System.Guid* type called *Guid*, and also creates its own type called *Guid* with a matching constructor interface. Later, the code creates an instance of the type *Guid*. To create this instance, the compiler must choose between the two different definitions of *Guid*. When the using-alias directive is placed outside of the namespace element, the compiler will choose the local definition of *Guid* defined within the local namespace, and completely ignore the using-alias directive defined outside of the namespace. This, unfortunately, is not obvious when reading the code.
+
 When the using-alias directive is positioned within the namespace, however, the compiler has to choose between two different, conflicting *Guid* types both defined within the same namespace. Both of these types provide a matching constructor. The compiler is unable to make a decision, so it flags the compiler error.
+
 Placing the using-alias directive outside of the namespace is a bad practice because it can lead to confusion in situations such as this, where it is not obvious which version of the type is actually being used. This can potentially lead to a bug which might be difficult to diagnose.
+
 Placing using-alias directives within the namespace element eliminates this as a source of bugs. 
 
 ### 2. Multiple Namespaces
 
 Placing multiple namespace elements within a single file is generally a bad idea, but if and when this is done, it is a good idea to place all using directives within each of the namespace elements, rather than globally at the top of the file. This will scope the namespaces tightly, and will also help to avoid the kind of behavior described above.
+
 It is important to note that when code has been written with using directives placed outside of the namespace, care should be taken when moving these directives within the namespace, to ensure that this is not changing the semantics of the code. As explained above, placing using-alias directives within the namespace element allows the compiler to choose between conflicting types in ways that will not happen when the directives are placed outside of the namespace.
 
 ## How to Fix Violations

diff --git a/documentation/SA1214.md b/documentation/SA1214.md
@@ -1,17 +1,17 @@
-## 
+## SA1214
 
 <table>
 <tr>
   <td>TypeName</td>
-  <td></td>
+  <td>SA1214StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements</td>
 </tr>
 <tr>
   <td>CheckId</td>
-  <td></td>
+  <td>SA1214</td>
 </tr>
 <tr>
   <td>Category</td>
-  <td></td>
+  <td>Ordering Rules</td>
 </tr>
 </table>
 
@@ -34,6 +34,6 @@ To fix an instance of this violation, place all static readonly elements above a
 ```
 
 ```csharp
-#pragma warning disable  // 
-#pragma warning restore  // 
+#pragma warning disable SA1214 // StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements
+#pragma warning restore SA1214 // StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements
 ```
diff --git a/documentation/SA1215.md b/documentation/SA1215.md
@@ -1,17 +1,17 @@
-## 
+## SA1215
 
 <table>
 <tr>
   <td>TypeName</td>
-  <td></td>
+  <td>SA1215InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements</td>
 </tr>
 <tr>
   <td>CheckId</td>
-  <td></td>
+  <td>SA1215</td>
 </tr>
 <tr>
   <td>Category</td>
-  <td></td>
+  <td>Ordering Rules</td>
 </tr>
 </table>
 
@@ -34,6 +34,6 @@ To fix an instance of this violation, place all instance readonly elements above
 ```
 
 ```csharp
-#pragma warning disable  // 
-#pragma warning restore  // 
+#pragma warning disable SA1215 // InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements
+#pragma warning restore SA1215 // InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements
 ```
diff --git a/documentation/SA1300.md b/documentation/SA1300.md
@@ -21,7 +21,7 @@ The name of a C# element does not begin with an upper-case letter.
 
 ## Rule Description
 
-A violation of this rule occurs when the names of certain types of elements do not begin with an upper-case letter. The following types of elements should use an upper-case letter as the first letter of the element name: *namespaces, classes, enums, structs, delegates, events, methods, *and* properties*.
+A violation of this rule occurs when the names of certain types of elements do not begin with an upper-case letter. The following types of elements should use an upper-case letter as the first letter of the element name: *namespaces, classes, enums, structs, delegates, events, methods,* and *properties*.
 
 In addition, any field which is public, internal, or marked with the const attribute should begin with an upper-case letter. Non-private readonly fields must also be named using an upper-case letter.
 

diff --git a/documentation/SA1311.md b/documentation/SA1311.md
@@ -1,17 +1,17 @@
-## 
+## SA1311
 
 <table>
 <tr>
   <td>TypeName</td>
-  <td></td>
+  <td>SA1311StaticReadonlyFieldsMustBeginWithUpperCaseLetter</td>
 </tr>
 <tr>
   <td>CheckId</td>
-  <td></td>
+  <td>SA1311</td>
 </tr>
 <tr>
   <td>Category</td>
-  <td></td>
+  <td>Naming Rules</td>
 </tr>
 </table>
 
@@ -21,13 +21,11 @@ The name of a static readonly field does not begin with an upper-case letter.
 
 ## Rule Description
 
-A violation of this rule occurs when the name of a static readonly field begins 
-                    with a lower-case letter. 
+A violation of this rule occurs when the name of a static readonly field begins with a lower-case letter. 
 
 ## How to Fix Violations
 
-To fix a violation of this rule, change the name of the field so that it begins with an 
-                    upper-case letter.
+To fix a violation of this rule, change the name of the field so that it begins with an upper-case letter.
 
 ## How to Suppress Violations
 
@@ -36,6 +34,6 @@ To fix a violation of this rule, change the name of the field so that it begins
 ```
 
 ```csharp
-#pragma warning disable  // 
-#pragma warning restore  // 
+#pragma warning disable SA1311 // StaticReadonlyFieldsMustBeginWithUpperCaseLetter
+#pragma warning restore SA1311 // StaticReadonlyFieldsMustBeginWithUpperCaseLetter
 ```