Coding Standards

Introduction

A consistent naming pattern is one of the most important elements of predictability and discoverability in programming. This article explains the coding standard I follow for my personal projects and at times at work as well. These are based on guidelines from Microsoft and other industry experts.

Capitalization Styles

• Pascal Case: Capitalize the first character of each word. Example: EmployeeBirthDate.
• Camel Case: Capitalize the first character of each word except the first word. Example: averageBirthRate.
• Upper Case: Capitalize all the letters in the word. Example: SUMASSURED.

C#.NET Coding Standards

Naming

• Solution/Assembly/Namespace: Pascal Case; CompanyName.TechnologyName[.Feature][.Design]
• Class: Pascal Case; Noun or noun phrase; No prefixes, underscores; Can have suffixes like: BaseClassName, Exception, Colllection, Delegate, Attribute.
• Interface: Pascal Case; I prefix.
• Enum type, values: Pascal Case; No Enum suffix.
• Event: Pascal Case;
• Event handlers: Pascal case; Use EventHandler suffix.
• Method: Pascal Case
• Parameter: Camel Case; No Hungarian (int, str) prefixes.
• Property: Pascal Case
• Class level variables: Camel Case; No Hungariam, No underscore or m_ prefixes, use this.variableName while referring it. Private; Public or Protected should not be used, use properties instead.
• Method level variables: Camel Case
• Constant: Pascal Case (Public) or Camel Case (Private); No ALL_CAPS.
• Control: Pascal Case; No Hungarian or ux prefixes; Suffix control base name: EmployeeNameLabel, EmployeeNameField, CancelButton, AccountsMenu, BottomStatusBar, MainPanel.

Naming General

• Case Sensitivity: Do not use names that require case sensitivity (void MyFunction(string a, string A)).
• Abbreviations: Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
• Acronyms: Only popular acronyms (UI, Olap); All caps only if two letters, otherwise Pascal Case.
• Word Choice: Avoid using keywords and .NET Framework class names.

Formatting

• Format: Use Visual Studio's default code format option always (Ctrl+K+D or Edit > Advanced > Format Document).
• Braces: At the beginning of the line after the statement except for single line statements. Always use even for single line.
• Comments (Routines): All routines should have xml (///) comments explaning its purpose.
• Comments (Code): Use two slash (//) comemnts just above a line if it requires more explanation. Do not ues at the end of line.
• Task Lists: Use Task List comment tokens (TODO, HACK, UNDONE) to indicate code areas that need to be revisited. (Visible in Task List Cttl + \ + T).
• Using: Using statements should be inside the namespace declaration.
• Grouping: Members in a class should be grouped (Fields, Constructors, Properties, Events, Methods, Interface Implementations, Nested Types) and should be in alphabetic order within groups.

Guidelines

• Source Files: Only one type within a source file. File name is class name.
• Constructor: Always provide a constructor to the class; If it is not expected to instantiate, make it private; provide overloads to set all properties; Do not add more code in constructors.
• Constants: Use public static read-only fields for predefined object instances.
• Parameter: Perform argument validation for every public or protected method and property set accessor. Throw meaningful ArgumentException exceptions to the developer for invalid parameter arguments.
• Nested Type: A nested type is a type defined within the scope of another type. Use it if it logically belongs to contaning type and need not be instantiated/used separately.

Database Standards

Naming

• General: Pascal Case; No prefixes like sp, tab, vw; No underscores; Only letters. Avoid keywrods.
• Database: Give the app name without a DB suffix (Northwind, not NorthwindDb).
• Table: Always singular (Customer, not Customers).
• Column: Singular except where in multiple values are stored. Do not repeat table names except for Id and Name. Can have meaningful suffixes:
  • Primary key: Id (EmployeeId)
  • Name field: Name (EmployeeName)
  • Description: Remarks (WorkRemarks)
  • Numbers: Number (RegistrationNumber)
  • Dates: Date (BirthDate, HireDate)
  • Money: Amount (TotalAmount)
  • Values: Value (AverageValue)
  • Boolean/Bit: Flag (ActiveFlag, ValidFlag)
• View/Stored Procedure/Function/Trigger: Use ‘Noun-Verb’ style naming to indicate the purpose; Use meaningful suffixes:
  • Create: EmployeeCreate
  • Read: EmployeeReadById, EmployeeReadByName, EmployeeReadAll
  • Update: EmployeeUpdate
  • Delete: EmployeeDelete
  • Process: SalaryCalculate, DividentDistribute, MarkAllocateByMerit

General

• Primary Key: All the tables should have a surrogate primary key. Use Identity fields except in data merging scenarios where Guid is best. A surrogate key should be completely behind the scenes. Users should never see them on reports, they should never be able to look up rows with them, etc. In addition, you should have a natural key, which by definition must be unique. That uniqueness should be enforced in your data model.
• Natural Key: A natural key is a naturally occurring descriptor of the data and one of a table's attributes that has no duplicate values. When you use a natural key as a table's primary key, each of the table's rows is uniquely identified. (Example: CustomerNumber: ALFKI).
• Surrogate Key: A surrogate key is an artificially produced value, most often a system-managed, incrementing counter whose values can range from 1 to n, where n represents a table's maximum number of rows. (Example: CustomerId: 12). It will have no business meaning and hence will be easy to maintain even if business rules change (Example: Customer Number was modified to include numbers).

Links

• https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines
• http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices