# Naming Conventions

The naming conventions described in the following sections should be adhered to for all new development. Exceptions to this rule include maintenance to projects that deviate significantly from the standards. In these cases, the Developer will follow the existing conventions of the project.

Developers may also capitalize identifiers to maintain compatibility with existing symbol schemes, where all uppercase characters are often used for enumerations and constant values. In general, these symbols should not be visible outside of the assembly that uses them.

• DO choose easily readable identifier names.
• DO favor readability over brevity.
• DO NOT use Hungarian notation.
• AVOID using identifiers that conflict with keywords of widely used programming languages.

• DO NOT use abbreviations or contractions as part of identifier names.
• DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary.
• DO use meaningful names based on the type or entity for short variable names within lambda expressions (e.g. r for a Request not x).

• DO use semantically interesting names rather than language-specific keywords for type names.
• DO use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type (e.g. GetInt64 not GetLong).
• DO use a common name, such as Value or Item, rather than repeating the type name, in the rare cases when an identifier has no semantic meaning and the type of the parameter is not important.

• DO name classes and structs with nouns or noun phrases.
• DO name interfaces with adjective phrases, or occasionally nouns or noun phrases.

• DO name methods using a verb or verb phrase.

• DO name properties using a noun, noun phrase, or adjective.
• DO name collection properties with a plural phrase describing the items in the collection instead of using a singular phrase followed by List or Collection.

• DO name events with a verb or verb phrase.
• DO give events names with a concept of before and after, using the present and past tenses.
• DO NOT use Before or After prefixes or postfixes to indicate pre- and post-events.
• DO name event handlers (delegates used as types of events) with the EventHandler suffix.
• DO use two parameters named sender and e in event handlers.
• DO name event argument classes with the EventArgs suffix.

• AVOID public or protected instance fields.
• DO name fields using a noun, noun phrase, or adjective.

• DO use descriptive parameter names.
• CONSIDER using names based on a parameter’s meaning rather than the parameter’s type.

• Object names will consist of meaningful words separated by an underscore character (e.g., tbl_Loan_Type). Exceptions include tables imported from a vendor database.
• Abbreviations should be avoided. Industry standard abbreviations or acronyms may be used to avoid excessively long names.
• Singular forms will be used for table and view names.
• Tables containing many-to-many relationships will consist of the names of representative tables followed by Holder (e.g., tbl_User_Role_Holder).
• Column names will consist of the table name followed by a descriptive column name (e.g. User_Last_Name). Exceptions include foreign keys to other tables and columns imported from a vendor database.
• Synthetic key names will consist of the table name followed by Ref (e.g., User_Ref).
• Stored procedure names will consist of the table name followed by the action (e.g., stp_Loan_Select, stp_Loan_Update, etc.).
• Database user names for application connections will consist of proc followed by the database name (e.g., proc_NetworkInventory). Special-purpose database user names may have a suffix added (e.g., proc_NetworkInventoryReporting).

Name classes for their purpose; not their appearance.

/* good */
.error {
    color: red;
}

/* bad */
.red {
    color: red;
}