C# Coding Standards and Naming Conventions

Below are our C# coding standards, naming conventions, and best practices.

Use these in your own projects and/or adjust these to your own needs.

do

public class ClientActivity { public void ClearStatistics() { //... } public void CalculateStatistics() { //... } }

do

public class UserLog { public void Add(LogEvent logEvent) { int itemCount = logEvent.Items.Count; // ... } }

do not

// Correct int counter; string name; // Avoid int iCounter; string strName;

do not

// Correct public static const string ShippingType = "DropShip"; // Avoid public static const string SHIPPINGTYPE = "DropShip";

avoid

// Correct UserGroup userGroup; Assignment employeeAssignment; // Avoid UserGroup usrGrp; Assignment empAssignment; // Exceptions CustomerId customerId; XmlDocument xmlDocument; FtpHelper ftpHelper; UriPart uriPart;

do

HtmlHelper htmlHelper; FtpTransfer ftpTransfer; UIControl uiControl;

do not

// Correct public DateTime clientAppointment; public TimeSpan timeLeft; // Avoid public DateTime client_Appointment; public TimeSpan time_Left; // Exception private DateTime _registrationDate;

do

// Correct string firstName; int lastIndex; bool isSaved; // Avoid String firstName; Int32 lastIndex; Boolean isSaved;

do

var stream = File.Create(path); var customers = new Dictionary (); // Exceptions int index = 100; string timeSheet; bool isCompleted;

do

public class Employee { } public class BusinessLocation { } public class DocumentCollection { }

do

I

public interface IShape { } public interface IShapeCollection { } public interface IGroupable { }

do

// Located in Task.cs public partial class Task { //... }

// Located in Task.generated.cs public partial class Task { //... }

do

// Examples namespace Company.Product.Module.SubModule namespace Product.Module.Component namespace Product.Layer.Module.Group

do

// Correct class Program { static void Main(string[] args) { } }

do

// Correct public class Account { public static string BankName; public static decimal Reserves; public string Number {get; set;} public DateTime DateOpened {get; set;} public DateTime DateClosed {get; set;} public decimal Balance {get; set;} // Constructor public Account() { // ... } }

do

// Correct public enum Color { Red, Green, Blue, Yellow, Magenta, Cyan } // Exception [Flags] public enum Dockings { None = 0, Top = 1, Right = 2, Bottom = 4, Left = 8 }

do not

// Don't public enum Direction : long { North = 1, East = 2, South = 3, West = 4 } // Correct public enum Direction { North, East, South, West }

do not

// Don't public enum CoinEnum { Penny, Nickel, Dime, Quarter, Dollar } // Correct public enum Coin { Penny, Nickel, Dime, Quarter, Dollar }

usefor class names and method names.: consistent with the Microsoft's .NET Framework and easy to read.usefor local variables and method arguments.: consistent with the Microsoft's .NET Framework and easy to read.usenotation or any other type identification in identifiers: 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.usefor constants or readonly variables: consistent with the Microsoft's .NET Framework. Caps grap too much attention.using. Exceptions: abbreviations commonly used as names, such as: consistent with the Microsoft's .NET Framework and prevents inconsistent abbreviations.usefor abbreviations 3 characters or more (2 chars are both uppercase): consistent with the Microsoft's .NET Framework. Caps would grap visually too much attention.usein identifiers. Exception: you can prefix private static variableswith an underscore.: consistent with the Microsoft's .NET Framework and makes code more natural to read (without 'slur'). Also avoids underline stress (inability to see underline).useinstead of system type names like Int16, Single, UInt64, etc: consistent with the Microsoft's .NET Framework and makes code more natural to read.use implicit typefor local variable declarations. Exception: primitive types (int, string,double, etc) use predefined names.: removes clutter, particularly with complex generic types. Type is easily detected with Visual Studio tooltips.use noun or noun phrases to name a class.: consistent with the Microsoft's .NET Framework and easy to remember.prefix interfaces with the letter. Interface names are noun (phrases) or adjectives.: consistent with the Microsoft's .NET Framework.name source files according to their main classes. Exception: file names with partial classesreflect their source or purpose, e.g. designer, generated, etc.: consistent with the Microsoft practices. Files are alphabetically sorted and partial classes remain adjacent.organize namespaces with a clearly defined structure: consistent with the Microsoft's .NET Framework. Maintains good organization of your code base.vertically align curly brackets.: Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets.declare all member variables at the top of a class, with static variables at the very top.: generally accepted practice that prevents the need to hunt for variable declarations.use singular names for enums. Exception: bit field enums.: 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').explicitly specify a type of an enum or values of enums (except bit fields): can create confusion when relying on actual types and values.suffix enum names with Enum: consistent with the Microsoft's .NET Framework and consistent with prior rule of no type indicators in identifiers.