Define Your .NET Coding Standards

These days, software development is accomplished by several developers. Many team members work on code during development, but in most cases, it is unlikely that the code is maintained by those same developers long after it is installed into production. For this and many other reasons, a good set of standards and best practices should be defined for your organization. The following standards are used by my development team and I, but feel free to adopt and change these standards and practices to best fit the needs of your organization. Also, look into what other organizations in your industry are using. Note: All code examples are in VB .NET but most can apply to C# .NET as well.

Environment

It is extremely important, when coding in .NET, to enable Option Explicit and Option strict for all projects. This forces developers to explicitly declare and type variables before they are used. The compiler will generate more efficient machine code and significantly increase application performance.

Formatting

Formatting makes the logical organization of the code obvious. Taking the time to ensure that the source code is formatted in a consistent, logical manner is helpful to you and to other developers who must decipher the source code.

1. Align blocks of code using indentation.

2. Keep maximum line length for comments and code to a reasonable length to avoid having to scroll the source code editor. This strategy also provides cleaner hard copy presentation.

3. Use line breaks between logical blocks of code. Doing so creates "paragraphs" of code, which aid the reader in comprehending the logical segmenting of the software.

4. Place the concatenation operator (“_”) at the end of each line instead of at the beginning.

5. Do not use an underscore (“_”) in function names except for event handlers.

6. Develop and use structured error-handling routines where applicable. This includes file IO, database operations, and network operations.

7. Explicitly release object references.

8. Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
9. Do not use acronyms that are not generally accepted in the computing field.
10. Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
11. When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
12. When writing SQL statements, use all uppercase for keywords and mixed case for database elements, such as tables, columns, and views.
13. Put each major SQL clause on a separate line so that statements are easier to read and edit.

Variables

Good variable naming standards and practices is vital in creating code that is easily understood and maintained. In most situations, the developer working with code is not the developer who originally wrote it. There are three naming standards that you should be aware of:

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example:

Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example:

Refer to these capitalization styles for the variable naming standards below.

1. Keep the scope of variables as small as possible to avoid confusion and to ensure maintainability.
2. Use Camel case for local variables and parameters

   

3. Use Pascal case for namespaces, properties, enumerated values, classes, events, methods and functions.
4. Use the prefixes below for visual objects used on your forms. This lets you and other developers know what object type you are working with, and aids in readability and understanding of your code. For client-side objects, declared variables, and visual objects that are not used such as static labels, no prefix is necessary.
   

LBL - Label
GRD or GRID - GridView
TXT - Textbox
DL - DataList
CMD or BUT - Button
DTL - DetailsList
CMD or BUT - LinkButton
FMV - FormView
CMD or BUT - ImageButton
REP - Repeater
LNK - HyperLink
DS - SqlDataSource
CMB or DDL - DropDownList
DS - AccessDataSource
LST - ListBox
DS - ObjectDataSource
CHK - Checkbox
DS - XmlDataSource
CHK - CheckboxList
DS - SiteMapDataSource
OPT - RadioButton
RTV - ReportViewer
OPT - RadioButtonList
IMG - Image
IMG - ImageMap
TBL - Table
UOL - BulletedList
HID - HiddenField
LIT - Literal
CAL - Calendar
AD - AdRotator
FUL - FileUpload
WIZ - Wizard
XML - XML
MLV - MultiView
PNL - Panel
PLH - PlaceHolder
VIEW - View
SUB - Substitution
LOC - Localize

SQL

Using a naming standard and good practices for the SQL statements in your project will make your queries easier to read and understand, which will make the underlying dataset and relevant code easier to understand as well.

1. Capitalize keywords.

2. Never use “SELECT *”
3. Do not use prefixes for database objects. For example, use Employee instead of tblEmployee.
4. Database object names should be singular. For example, name a table “Order” instead of “Orders”.
5. When creating a SQL query in your code, put each statement on a separate line.

6. Avoid using reserved keywords for database object or field names. You can use the SQL Reserved Words Checker located at http://www.petefreitag.com/tools/sql_reserved_words_checker to make sure.