h1.post-title { color:orange; font-family:verdana,Arial; font-weight:bold; padding-bottom:5px; text-shadow:#64665b 0px 1px 1px; font-size:32px; } -->

Pages

C# coding Guide

C# coding Guide
Bracing
           Open braces should always be at the beginning of the line after the statement that begins the block. Contents of the brace should be indented by 4 spaces. For example: “case” statements should be indented from the switch statement like this: Braces should never be considered optional. Even for single statement blocks, you should always use braces. This increases code readability and maintainability. Single line statements Single line statements can have braces that begin and end on the same line. It is suggested that all control structures (if, while, for, etc.) use braces, but it is not required.
Spacing
         Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

  • Do use a single space after a comma between function arguments. 
  • Do not use a space after the parenthesis and function arguments 
  • Do not use spaces between a function name and parenthesis. 
  • Do not use spaces inside brackets. 
  • Do use a single space before flow control statements 
  • Do use a single space before and after comparison operators 

Naming 
       Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

  • Do not use Hungarian notation 
  • Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET. Do use camelCasing for member variables 
  • Do use camelCasing for parameters 
  • Do use camelCasing for local variables 
  • Do use PascalCasing for function, property, event, and class names 
  • Do prefix interfaces names with “I” Do not prefix enums, classes, or delegates with any letter 

Interop Classes 
          Classes that are there for interop wrappers (DllImport statements) should follow the naming convention below:
NativeMethods
           No suppress unmanaged code attribute, these are methods that can be used anywhere because a stack walk will be performed.
UnsafeNativeMethods
            Has suppress unmanaged code attribute. These methods are potentially dangerous and any caller of these methods must do a full security review to ensure that the usage is safe and protected as no stack walk will be performed.
SafeNativeMethods 
           Has suppress unmanaged code attribute. These methods are safe and can be used fairly safely and the caller isn’t needed to do full security reviews even though no stack walk will be performed. All interop classes must be private, and all methods must be internal. In addition a private constructor should be provided to prevent instantiation.
File Organization
        Source files should contain only one public type, although multiple internal classes are allowed
        Source files should be given the name of the public class in the file Directory names should follow the namespace for the class
For example, I would expect to find the public class “System.Windows.Forms.Control” in “System\Windows\Forms\Control.cs"
Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types) Using statements should be inside the namespace declaration.