Layout Guidelines

Edit this page

Use a common layout (RG2400)

  • Keep the length of each line under 130 characters.

  • Use an indentation of 4 spaces, and don’t use tabs

  • Keep one space between keywords like if and the expression, but don’t add spaces after ( and before ) such as: if (condition == null).

  • Add a space around operators like +, -, ==, etc.

  • Always put opening and closing curly braces on a new line.

  • Don’t indent object/collection initializers and initialize each property on a new line, so use a format like this:

      var dto = new ConsumerDto
          Id = 123,
          Name = "Microsoft",
          PartnerShip = PartnerShip.Gold,
          ShoppingCart =
              ["VisualStudio"] = 1
  • Don’t indent lambda statement blocks and use a format like this:

      methodThatTakesAnAction.Do(x =>
          // do something like this 
  • Keep expression-bodied-members on one line. Break long lines after the arrow sign, like this:

      private string GetLongText =>
  • Put the entire LINQ statement on one line, or start each keyword at the same indentation, like this:

      var query = from product in products where product.Price > 10 select product;
      var query =  
          from product in products  
          where product.Price > 10  
          select product;
  • Start the LINQ statement with all the from expressions and don’t interweave them with restrictions.
  • Add parentheses around every binary expression, but don’t add parentheses around unary expressions. For example if (!string.IsNullOrEmpty(str) && (str != "new"))

  • Add an empty line between multi-line statements, between multi-line members, after the closing curly braces, between unrelated code blocks, around the #region keyword, and between the using statements of different root namespaces.

Order and group namespaces according to the company (RG2402)

// Microsoft namespaces are first
using System;
using System.Collections.Generic;
using System.XML;

// Then any other namespaces in alphabetic order
using AvivaSolutions.Business;
using AvivaSolutions.Standard;
using Telerik.WebControls;
using Telerik.Ajax;

Using static directives and using alias directives should be written below regular using directives. Always place these directives at the top of the file, before any namespace declarations (not inside them).

Place members in a well-defined order (RG2406)

Maintaining a common order allows other team members to find their way in your code more easily. In general, a source file should start off describing any global or static state, then instance state (including auto-properties), so the state encapsulated by a class can be immediately determined.

Expression-bodied public properties and events are important parts of the interface to an object but can be difficult to notice if they are interleaved between longer methods. Grouping them together helps to ensure that they stand out.

  1. Constants and static readonly fields (public or private)
  2. Private fields
  3. Auto-properties
  4. Events
  5. Constructors
  6. Factory methods
  7. Expression-bodied public properties
  8. Other methods and properties, preferring to keep private methods close to public methods that use them
  9. Nested classes

Be reluctant with #region (RG2407)

Regions can be helpful, but can also hide the main purpose of a class.

Use expression-bodied members appropriately (RG2410)

Favor expression-bodied member syntax over regular member syntax only when:

  • the body consists of a single statement and
  • the body fits on a single line.