C# Coding Standards 😎

• All comments should be written in U.S. English.
• Use // or /// but do NOT use /* */.
• Commented out code should be code that will be soon deleted, and marked with a TODO:.
• Do not "flowerbox" comment blocks.
  
  Example
  
  Bad
  

  // ********************************

  // Comment block

  // ********************************
  
  Good
  

  // ********************************

  // Comment block
  

• Use inline-comments to explain assumptions, known issues, and algorithm insights.
• Do not use inline-comments to explain obvious code. Well written code is self documenting.
• Use "TODO:" task list tokens to mark incomplete methods or sections.
  
  Example
  

  // TODO: handle validation errors
  

• Do NOT use "HACK" or "UNDONE" task list tokens. Other tokens may be added with team consensus and they are added to this document to define how they are to be used.
• Always apply C# comment-blocks (///) to classes. Class comment block should include the following.
  
  • Required
    
    • Summary (<summary>): used to define what the class is used for
      
  • Optional
    
    • Remarks (<remarks>): used to provide further explanation of the class use
• Always apply C# documentation comment blocks (///) to constructors, properties, and methods. Comment blocks should include the following sections.
  
  • Required
    
    • Summary (<summary>): used to define what the constructor, property, or method is used for.
      
  • Conditional
    
    • Param (<param name="theNameOfTheParameter">): Required for each parameter passed to the constructor or method. Should include what the parameter its primary use.
    • Returns (<returns>): Required for any method that returns a value. Should describe the returned data type and a description of what it is set to.
  • Optional
    
    • Remarks (<remarks>): Used to convey more information about the method. This may include pseudo-code for complicated methods.
    • Exception (<exception cref="CoConGeneralException">): Used to indicate what exception(s) are potentially thrown by the method.
      
• Additional C# document comment blocks guidelines
  
  • Add a blank line between the sections for readability.
  • Sections should be ordered as follows:
    • Summary
    • Param
    • Return
    • Remark
    • Exception

3.3 Visual Studio .Net Environment Setup

• Select Tools/Options
• Select Text Editor
• Select All Languages/Tabs and set the following:
  
  
  • Indenting: Block
  • Tab Size: 2
  • Tab Indent Size: 2
  • Select "Insert Spaces"
• Select C#/Formatting/General: check all checkboxes
• Select C#/Formatting/Indentation: check all checkboxes except "Indent open and close braces" that should be unchecked.
• Select C#/Formatting/New Lines: check all checkboxes

4. Language Usage

4.1 Variables and Types

• Do not omit access modifiers. Explicitly declare all identifiers with the appropriate access modifier instead of allowing the default.
  
  Example
  

  // Bad!

  void WriteEvent(string message)

  {

  }

  // Good!

  privatevoid WriteEvent(string message)

  {

  }

• Declare all variables at the beginning of a method and initialize object variables to null. Scalar variables do not need to be initialized at declaration.
• Use the simplest data type, list, or object required. For example, use int over long unless you know you need to store 64 bit values.
• Always use the built-in data type aliases, not the .NET common type system (CTS).
  
  Example
  
  
  • short not System.Int16
  • int not System.Int32
  • long not System.Int64
  • string not System.String
    
• Declare instance variables as private. Use properties to provide access to them with public, protected, or internal access modifiers as applicable.
• enum: should be int unless you have an explicit need for long.
• Avoid using inline numeric literals (magic numbers). Instead, use a constant or enum.
• Avoid declaring inline string literals. Instead use constants, resources or other data sources.
• Use the @ prefix when initializing string constants or variables instead of escaped strings.
  
  Example
  
  Bad
  
  private const string PATH = "C:\\Projects\\CoCon\\";
  
  Good
  
  private const string PATH = @"C:\Projects\CoCon\";
  
• For string template construction, use String.Format()
• For string concatenation being performed more than once on a string, use StringBuilder
• Avoid concatenating strings inside a loop. Use StringBuilder if concatenation is required inside the loop.
• Do not compare strings to String.Empty or "" to check for empty strings. Use String.IsNullOrEmpty or myString.Length == 0
• When comparing one string to another, use myString1.Equals(myString2)
• Avoid hidden string allocations, especially within a loop. NOTE: Strings are inmutable so changing the value of a string actually allocates a new string.
• Do not invoke methods in conditional statements
• Avoid creating recursive methods. Any perceived need for a recursive method must be reviewed by the team before implementation.

4.2 Exception Handling

• Do not use try/catch blocks for flow-control.
• Only catch exceptions when you can add value such as context information to the exception.
• Never declare an empty catch block. This results in "dumping the exception on the floor".
• Avoid nesting a try/catch within a catch block. Any perceived need for nested try/catch blocks must be reviewed by the team before implementation.
• Use exception filters where possible.
  
  Example
  
  

  catch(CoConGeneralException exc )

  {

  //do actions

  }

  catch(Exception exc)

  {

  //do actions

  }
  

• Order exception filters from most to least derived exception type.
• Avoid re-throwing an exception. Allow it to bubble-up if you can add no additional data to help with the debugging.
• Never use "e" as the variable for the exception. Use "exc" or an abbreviated version of the exception being caught.
• If re-throwing an exception, omit the exception argument from a throw statement to preserve the original call stack.
  
  Example
  

  // Bad

  catch(Exception exc)

  {

  Log(exc);

  throw exc;

  }

  // Good

  catch(Exception exc)

  {

  Log(exc);

  throw;

  }
  

• Only use the finally block to release resources from a try statement.
• When retrieving a DataTable, and expecting only zero or one rows, throw an Exception if the Rows.Count value is anything else
  
  Example
  

  dataTable = DBService.ExecuteQuery(sql);

  switch (dataTable.Rows.Count)

  {

  case 0:

  // process no rows case

  break;

  case 1:

  // process single row case

  break;

  default:

  ArgumentException exc = newArgumentException("Error message here");

  throw exc;
  }

5. Database

Given that data classes will be using inline, dynamic, parameterized SQL for database access, the following sets of guidelines will be followed.

• Use the SELECT constant to select columns. Do not use "SELECT *".
• Always declare all column names as constants.
• Always use parameters in a SQL statement instead of inline variables for all data.
• When transactions are used, each Begin must be matched with a Rollback/Commit.
• For complex statements, please feel free to consult a DBA for query optimization advice.

Hope that would help somebody. you can also download the guidelines, please find it attached.