S TA ND ARD C Sharp Coding Convention Code 09me-HD/PM/HDCV/FSOFT Version 1/0 Effective date 20/06/2005 Guideline: C Sharp Coding Standard v1/0 RECORD OF CHANGE *A - Added M - Modified D - Deleted Effective Changed Items A* Change Description New Version Date M, D 22-Apr-05 Firstly created First release version v1.0 09me-HD/PM/HDCV/FSOFT 2/57 Guideline: C Sharp Coding Standard v1/0 TABLE OF CONTENTS Record of change. Namespace Naming Guidelines. Class Naming Guideline .NET Naming class variable. Interface Naming Guideline.
Attribute Naming Guideline. Enumeration Type Naming Guideline. Static Field Naming Guideline. Parameter Naming Guideline.
Method Naming Guideline. Property Naming Guideline. Variable Naming Guideline. Event Naming Guideline.
Control Naming Standard. Constant Naming Guideline. Various data types. Object oriented programming.
37 09me-HD/PM/HDCV/FSOFT 3/57 Guideline: C Sharp Coding Standard v1/0 4. Delegates and events. PROJECT SETTINGS AND PROJECT STRUCTURE. FRAMEWORK SPECIFIC GUIDELINES .NET and Web Services.
56 09me-HD/PM/HDCV/FSOFT 4/57 Guideline: C Sharp Coding Standard v1/0 1. Purpose This document requires or recommends certain practices for developing programs in the C# language. The objective of this coding standard is to have a positive effect on: Avoidance of errors/bugs, especially the hard-to-find ones Maintainability, by promoting some proven design principles Maintainability, by requiring or recommending a certain unity of style Performance, by dissuading wasteful practices 1. Application scope All projects developed in C Sharp will be under scope of this standard.
Related documents No. Code Name of documents 1 2 09me-HD/PM/HDCV/FSOFT 5/57 Guideline: C Sharp Coding Standard v1/0 2. NAMING CONVENTION Naming conventions make programs more understandable by making them easier to read. This section lists the convention to be used in naming.
Capitalization Styles We will use the three following conventions for capitalizing identifiers. 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: BackColor Camel case The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized.
For example: backColor Uppercase All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example: System.UI; You might also have to capitalize identifiers to maintain compatibility with existing, unmanaged 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.
The following table summarizes the capitalization rules and provides examples for the different types of identifiers. Identifier Case Example Class Pascal AppDomain Enum Type Pascal ErrorLevel 09me-HD/PM/HDCV/FSOFT 6/57 Guideline: C Sharp Coding Standard v1/0 Identifier Case Example Enum Value Pascal FatalError Event Pascal ValueChange WebException Exception class Pascal Note: Always ends with the suffix Exception Read-only Static Pascal RedValue field IDisposable Interface Pascal Note: Always begins with the prefix I Method Pascal ToString Namespace Pascal System.Drawing Parameter Camel typeName Property Pascal BackColor redValue Protected instance Camel Note: Rarely used. A property is preferable to using a field protected instance field RedValue Public instance Pascal Note: Rarely used. A property is preferable to using a field public instance field 2.
Abbreviations To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations: Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin. Do not use acronyms that are not generally accepted in the computing field. 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. 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.
Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use Camel Case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word. 09me-HD/PM/HDCV/FSOFT 7/57 Guideline: C Sharp Coding Standard v1/0 2. Namespace Naming Guidelines.
The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows.Design] For example: Microsoft.Design Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name. For example, Microsoft.Office is an appropriate prefix for the Office Automation Classes provided by Microsoft. Use a stable, recognized technology name at the second level of a hierarchical name. Use organizational hierarchies as the basis for namespace hierarchies.
Name a namespace that contains types that provide design-time functionality for a base namespace with the. For example, the System.Design Namespace contains designers and related classes used to design System.Forms based applications. A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Design depend on the classes in System.
However, the classes in System.UI do not depend on the classes in System. You should use Pascal case for namespaces, and separate logical components with periods, as in Microsoft. If your brand employs nontraditional casing, follow the casing defined by your brand, even if it deviates from the prescribed Pascal case. For example, the namespaces NeXT.WebObjects and ee.cummings illustrate appropriate deviations from the Pascal case rule.
Use plural namespace names if it is semantically appropriate. For example, use System.Collections rather than System. Exceptions to this rule are brand names and abbreviations. For example, use System.IO rather than System.
Do not use the same name for a namespace and a class. For example, do not provide both a Debug namespace and a Debug class. Finally, note that a namespace name does not have to parallel an assembly name. For example, if you name an assembly MyCompany.dll, it does not have to contain a MyCompany.
09me-HD/PM/HDCV/FSOFT 8/57 Guideline: C Sharp Coding Standard v1/0 2. Class Naming Guideline The following rules outline the guidelines for naming classes: Use a noun or noun phrase to name a class. Use Pascal case. Use abbreviations sparingly.
Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream. Do not use the underscore character (_). Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface.
This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate. Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class.
For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.
The following are examples of correctly named classes: public class FileStream public class Button public class String 2.NET Naming class variable Express the name of DataTable variables in the plural form. For example, use Employees rather than Employee. Do not repeat the table name in the column name. If the DataTable name is Employee, LastName is preferred over EmployeeLastName.
The exception is for ID fields contained in multiple tables, so that that Employees table may contain an EmployeeID field. 09me-HD/PM/HDCV/FSOFT 9/57 Guideline: C Sharp Coding Standard v1/0 Do not incorporate the data type in the name of a column. If the data type is later changed, and the column name is not changed, the column name would be misleading. For example, LastName is preferred over stringLastName.
Interface Naming Guideline The following rules outline the naming guidelines for interfaces: Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
Use Pascal case. Use abbreviations sparingly. Prefix interface names with the letter I, to indicate that the type is an interface. Use similar names when you define a class/interface pair where the class is a standard implementation of the interface.
The names should differ only by the letter I prefix on the interface name. Do not use the underscore character (_). The following are examples of correctly named interfaces. public interface IServiceProvider public interface IFormatable The following code example illustrates how to define the interface IComponent and its standard implementation, the class Component.
public interface IComponent { //Implementation code goes here } public class Component: IComponent { //Implementation code goes here } 2. Attribute Naming Guideline You should always add the suffix Attribute to custom attribute classes. The following is an example of a correctly named attribute class. public class ObsoleteAttribute() 09me-HD/PM/HDCV/FSOFT 10/57 Guideline: C Sharp Coding Standard v1/0 2.
Enumeration Type Naming Guideline The enumeration (Enum) value type inherits from the Enum Class. The following rules outline the naming guidelines for enumerations: Use Pascal case for Enum types and value names. Use abbreviations sparingly. Do not use an Enum suffix on Enum type names.
Use a singular name for most Enum types For example, do not name an enumeration type Protocols but name it Protocol instead. Consider the following example in which only one option is allowed. public enum Protocol { Tcp, Udp, Http, Ftp } Use a plural name for Enum types that are bit fields. Use a plural name for such enumeration types.
The following code snippet is a good example of an enumeration that allows combining multiple options. [Flags] public enum Protocol { CaseInsensitive = 0x01, WholeWordOnly = 0x02, AllDocuments = 0x04, Backwards = 0x08, AllowWidlcards = 0x10 } Always add the FlagsAttribute to a bit field Enum type. Static Field Naming Guideline The following rules outline the naming guidelines for static fields: Use nouns, noun phrases, or abbreviations of nouns to name static fields. Use Pascal case.
Do not use a Hungarian notation prefix on static field names. 09me-HD/PM/HDCV/FSOFT 11/57 Guideline: C Sharp Coding Standard v1/0 It is recommended that you use static properties instead of public static fields whenever possible. Parameter Naming Guideline It is important to carefully follow these parameter naming guidelines because visual design tools that provide context sensitive help and class browsing functionality display method parameter names to users in the designer. The following rules outline the naming guidelines for parameters: Use camel case for parameter names.
Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.
Do not use reserved parameters. Reserved parameters are private parameters that might be exposed in a future version if they are needed. Instead, if more data is needed in a future version of your class library, add a new overload for a method. Do not prefix parameter names with Hungarian type notation.
The following are examples of correctly named parameters. Method Naming Guideline The following rules outline the naming guidelines for methods: Use verbs or verb phrases to name methods. Use Pascal case.