Naming Conventions
C# Coding Standards and Naming Conventions
Do use PascalCasing for class names and method names:
public class SendMailService { public void SendMail() { //... } public async Task<bool> SendMailAsync() { //... } }
Do use camelCasing for method arguments and local variables:
public class AccountController { public Add(UserViewModel userViewModel) { var result = new GenericResult(int); //... }
Do NOT use Hungarian notation or any other type identification in identifiers
// Correct int counter; string name; // Avoid int iCounter; string strName;
Why: In general you want to avoid type indicators in any identifier.
Do NOT use Screaming Caps for constants or readonly variables
// Correct public static const string ShippingType = "DropShip"; // Avoid public static const string SHIPPINGTYPE = "DropShip"; public static const string SHIPPING_TYPE = "DropShip";
Why: Caps grap too much attention.
Avoid using Abbreviations. Exceptions: abbreviations commonly used as names, such as Id, Xml, Ftp, Uri.
// Correct UserGroup userGroup; Assignment employeeAssignment; // Avoid UserGroup usrGrp; Assignment empAssignment; // Exceptions CustomerId customerId; XmlDocument xmlDocument; FtpHelper ftpHelper; UriPart uriPart;
Why: Prevents inconsistent abbreviations.
Do use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase)
HtmlHelper htmlHelper; FtpTransfer ftpTransfer; UIControl uiControl;
Why: Caps would grap visually too much attention
Do NOT use Underscores in identifiers. Exception: you can prefix private static variables with an underscore.
// Correct DateTime modifiedDate; TimeSpan deltaTime; // Avoid public DateTime modified_date; public TimeSpan delta_time; // Exception private DateTime _modifiedDate;
Why: makes code more natural to read (without 'slur'). Also avoids underline stress (inability to see underline).
Do use predefined type names instead of system type names like Int16, Single, UInt64, etc
// Correct string firstName; int lastIndex; bool isSaved; // Avoid String firstName; Int32 lastIndex; Boolean isSaved;
Do use noun or noun phrases to name a class.
public class Employee {} public class BusinessLocation {}
Do prefix interfaces with the letter I. Interface names are noun (phrases) or adjectives.
public interface IShape {} public interface ITicketService {}
Do organize namespaces with a clearly defined structure
namespace Company.Product.Module.SubModule {} namespace Product.Module.Component {} namespace Product.Layer.Module.Group {}
Do vertically align curly brackets.
class Program { static void Main(string[] args) { } }
Why: Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets
Do declare all member variables at the top of a class, with static variables at the very top.
public class Account { public static string BankName; public static decimal Reserves; public DateTime DateOpened {get; set;} public decimal Balance {get; set;} // Constructor public Account() { // ... } }
Why: generally accepted practice that prevents the need to hunt for variable declarations.
Do use singular names for enums. Exception: bit field enums
// Correct public enum Color { Red, Green, Blue } // Exception [Flags] public enum Dockings { None = 0, Top = 1, Right = 2, Bottom = 4, Left = 8 }
Why: 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').
Do NOT explicitly specify a type of an enum or values of enums (except bit fields)
// Don't public enum Direction : long { North = 1, East = 2, South = 3, West = 4 } // Correct public enum Direction { North, East, South, West }
Why: can create confusion when relying on actual types and values.
Do NOT suffix enum names with Enum or Flags
// Don't public enum CoinEnum { Penny, Nickel, Dime } // Don't [Flags] public enum DockingsFlags { None = 0, Top = 1, Right = 2, Bottom = 4, Left = 8 } // Correct public enum Coin { Penny, Nickel, Dime } // Correct [Flags] public enum Dockings { None = 0, Top = 1, Right = 2, Bottom = 4, Left = 8 }
Why: consistent with prior rule of no type indicators in identifiers
Do use suffix EventArgs / EventHandler / Exception to comprising the information:
public class ThresholdReachedEventArgs : EventArgs {} public delegate void ThresholdReachedEventHandler(object sender, ThresholdReachedEventArgs e); public class ApiException : System.Exception {}
Offical Reference
Naming Conventions for ASP.NET Controls
In general, naming ASP.NET controls is made using Camel Case naming convention, where the prefix of the name is the abbreviation of the control type name.
Standard Controls
Prefix
Control
Example
btn
Button
btnSubmit
cb
CheckBox
cbTerms
cbl
CheckBoxList
cblTodos
ddl
DropDownList
ddlCountries
fu
FileUpload
fuVideo
hf
HiddenField
hfBookId
lnk
Hyperlink
lnkViewMore
img
Image
imgBanner
ibtn(btn)
ImageButton
ibtnDelete
lbl
Label
lblName
lbtn(btn)
LinkButton
lbtnSubmit
lb
ListBox
lbSelectedItems
lit
Literal
litOutput
mv
MultiView
mvContainer
pnl
Panel
pnlToggle
ph
PlaceHolder
phMessage
rb
RadioButton
rbStatus
rbl
RadioButtonList
rblPackages
tbl
Table
tblReport
txt
TextBox
txtEmail
v
View
vRegisterForm
Data Controls
Prefix
Control
Example
dtl(dl)
DataList
dtlMovie
dp
DataPager
dpMovie
dtv
DetailsView
dtvMovie
ets
EntityDataSource
etsMovie
fv
FormView
fvCheckout
gv
GridView
gvMovie
lds
LinqDataSource
ldsMovie
lv
ListView
lvMovie
ods
ObjectDataSource
odsMovie
qe
QueryExtender
qeMovie
rpt
Repeater
rptMovie
smd
SiteMapDataSource
smdSitemap
sds
SqlDataSource
sdsMovie
xds
XmlDataSource
xmlPosts
Validation Controls
Prefix
Control
Example
cpv
CompareValidator
cpvConfirmPassword
ctv
CustomValidator
cvPhoneNumber
rv
RangeValidator
rvLimit
rev
RegularExpressionValidator
revDomainUrl
rfv
RequiredFieldValidator
rfvName
vs
ValidationSummary
vsSummary
Last updated
Was this helpful?