Merge pull request #7 from RunninglVlan/patch-1

Added consistency in code formatting

C# Coding Standards and Naming Conventions.md

@@ -43,12 +43,12 @@ public class ClientActivity
     // ...
   }
 }
-	}
 ```
 
 ***Why: consistent with the Microsoft's .NET Framework and easy to read.***
 
 #### 3. Do not use Hungarian notation or any other type identification in identifiers
+
 ```csharp
 // Correct
 int counter;
@@ -60,7 +60,8 @@ public class ClientActivity
 
 ***Why: consistent with the Microsoft's .NET Framework and Visual Studio IDE makes determining types very easy (via tooltips). In general you want to avoid type indicators in any identifier.***
 
-#### 4. Do not use Screaming Caps for constants or readonly variables 
+#### 4. Do not use Screaming Caps for constants or readonly variables:
+
 ```csharp
 // Correct
 public static const string ShippingType = "DropShip";    
@@ -71,6 +72,7 @@ public class ClientActivity
 ***Why: consistent with the Microsoft's .NET Framework. Caps grap too much attention.***
 
 #### 5. Use meaningful names for variables. The following example uses seattleCustomers for customers who are located in Seattle:
+
 ```csharp
 var seattleCustomers = from cust in customers
   where cust.City == "Seattle" 
@@ -80,6 +82,7 @@ public class ClientActivity
 ***Why: consistent with the Microsoft's .NET Framework and easy to read.***
 
 #### 6. Avoid using Abbreviations. Exceptions: abbreviations commonly used as names, such as Id, Xml, Ftp, Uri.
+
 ```csharp    
 // Correct
 UserGroup userGroup;
@@ -96,7 +99,8 @@ public class ClientActivity
 
 ***Why: consistent with the Microsoft's .NET Framework and prevents inconsistent abbreviations.***
 
-#### 7. Do use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase) 
+#### 7. Do use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase):
+
 ```csharp  
 HtmlHelper htmlHelper;
 FtpTransfer ftpTransfer;
@@ -106,6 +110,7 @@ public class ClientActivity
 ***Why: consistent with the Microsoft's .NET Framework. Caps would grap visually too much attention.***
 
 #### 8. Do not use Underscores in identifiers. Exception: you can prefix private static variables with an underscore:
+
 ```csharp 
 // Correct
 public DateTime clientAppointment;
@@ -119,7 +124,8 @@ public class ClientActivity
 
 ***Why: consistent with the Microsoft's .NET Framework and makes code more natural to read (without 'slur'). Also avoids underline stress (inability to see underline).***
 
-#### 9. Do use predefined type names instead of system type names like Int16, Single, UInt64, etc
+#### 9. Do use predefined type names instead of system type names like Int16, Single, UInt64, etc.
+
 ```csharp
 // Correct
 string firstName;
@@ -163,6 +169,7 @@ public class ClientActivity
 ***Why: consistent with the Microsoft's .NET Framework and easy to remember.***
 
 #### 12. Do prefix interfaces with the letter I. Interface names are noun (phrases) or adjectives.
+
 ```csharp     
 public interface IShape
 {
@@ -183,12 +190,10 @@ public class ClientActivity
 // Located in Task.cs
 public partial class Task
 {
-		//...
 }
 // Located in Task.generated.cs
 public partial class Task
 {
-     	//...
 }
 ```
 
@@ -199,20 +204,27 @@ public class ClientActivity
 ```csharp 
 // Examples
 namespace Company.Product.Module.SubModule
+{
+}
 namespace Product.Module.Component
+{
+}
 namespace Product.Layer.Module.Group
+{
+}
 ```
 
 ***Why: consistent with the Microsoft's .NET Framework. Maintains good organization of your code base.***
 
-
 #### 15. Do vertically align curly brackets: 
+
 ```csharp 
 // Correct
 class Program
 {
   static void Main(string[] args)
   {
+    //...
   }
 }
 ```
@@ -220,6 +232,7 @@ public class ClientActivity
 ***Why: Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets.***
 
 #### 16. Do declare all member variables at the top of a class, with static variables at the very top.
+
 ```csharp 
 // Correct
 public class Account
@@ -237,9 +250,11 @@ public class ClientActivity
   }
 }
 ```
+
 ***Why: generally accepted practice that prevents the need to hunt for variable declarations.***
 
 #### 17. Do use singular names for enums. Exception: bit field enums.
+
 ```csharp 
 // Correct
 public enum Color
@@ -262,9 +277,11 @@ public class ClientActivity
   Left = 8
 }
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and makes the code more natural to read. Plural flags because enum can hold multiple values (using bitwise 'OR').***
 
-#### 18. Do not explicitly specify a type of an enum or values of enums (except bit fields) 
+#### 18. Do not explicitly specify a type of an enum or values of enums (except bit fields):
+
 ```csharp 
 // Don't
 public enum Direction : long
@@ -283,9 +300,11 @@ public class ClientActivity
   West
 }
 ```
+
 ***Why: can create confusion when relying on actual types and values.***
 
-#### 19. Do not use an "Enum" suffix in enum type names. 
+#### 19. Do not use an "Enum" suffix in enum type names:
+
 ```csharp     
 // Don't
 public enum CoinEnum
@@ -306,9 +325,11 @@ public class ClientActivity
   Dollar
 }
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and consistent with prior rule of no type indicators in identifiers.***
 
-#### 20. Do not use "Flag" or “Flags" suffixes in enum type names.
+#### 20. Do not use "Flag" or "Flags" suffixes in enum type names:
+
 ```csharp 
 // Don't
 [Flags]
@@ -331,26 +352,38 @@ public class ClientActivity
   Left = 8
 }
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and consistent with prior rule of no type indicators in identifiers.***
 
 #### 21. Do use suffix EventArgs at creation of the new classes comprising the information on event:
+
 ```csharp 
 // Correct
-    public void BarcodeReadEventArgs : System.EventArgs 
+public class BarcodeReadEventArgs : System.EventArgs
+{
+}
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and easy to read.***
 
 #### 22. Do name event handlers (delegates used as types of events) with the "EventHandler" suffix, as shown in the following example:
+
 ```csharp 
 public delegate void ReadBarcodeEventHandler(object sender, ReadBarcodeEventArgs e);
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and easy to read.***
 
-#### 23. Do not create names of parametres in methods (or constructors) which differ only the register:
+#### 23. Do not create names of parametres in methods (or constructors) which differ only by the register:
+
 ```csharp 
 // Avoid
 private void MyFunction(string name, string Name)
+{
+  //...
+}
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and easy to read, and also excludes possibility of occurrence of conflict situations.***
 
 #### 24. DO use two parameters named sender and e in event handlers. The sender parameter represents the object that raised the event. The sender parameter is typically of type object, even if it is possible to employ a more specific type.
@@ -360,10 +393,14 @@ public class ClientActivity
 ***Why: consistent with the Microsoft's .NET Framework and consistent with prior rule of no type indicators in identifiers.***
 
 #### 25. Do use suffix Exception at creation of the new classes comprising the information on exception:
+
 ```csharp 
 // Correct
-    public void BarcodeReadException : System.Exception 
+public class BarcodeReadException : System.Exception
+{
+}
 ```
+
 ***Why: consistent with the Microsoft's .NET Framework and easy to read.***
 
 ## Offical Reference