Commenting
Comments should be included throughout the code to document the intention of the code written, its dependencies, and how to use it. Other than an XML comment block, all code should be well commented.
General commenting rules
| Rule | Do |
|---|---|
| 1. | Use comments to explain what the code does, not how it does it. |
| 2. | Keep comments clear, correct, up to date, and meaningful - don’t comment on the obvious, and try to avoid large amounts of comments. |
| 3. | Indent comments with the same number of spaces as the associated code. |
| 4. | Make use of TODO comments as reminders for future action. |
| 5. | Once TODO comments are actioned, remove them. |
| 6. | Always apply XML comments for types and members, regardless of whether they are Public, Private or Friend. |
| Rule | Do Not |
| 7. | Don’t use end line comments, as they blend into the code. |
Section tags
Section tags are used to define the content of the different sections of the documentation of a type or member. These tags are used as top-level tags.
Tag: <code> Indicates that multiple lines should be marked as code.
Tag: <example> Specifies an example of how to use a method or other library member. Commonly, this would involve use of the <code> tag.
Tag: <exception> Specifies which exceptions can be thrown. This tag is applied to a method definition.
Tag: <history>
Details the change history of the file, and a stub is highly desirable to be included in every code file prior to production release. The typical template of a change history:
Who Date Task# Description======== ========== ========= ============================<userid> dd/mm/yyyy <TFS No.> Brief explanation of changes made.
The history of changes template should be added to the class comment header only. Prior to the first production release, Description = Created.
Tag: <include> Refers to comments in another file that describe the types and members in the source code. This is an alternative to placing documentation comments directly in the source code file.
Tag: <param> Describes one of the parameters for the method.
Tag: <permission> Documents the access of a member.
Tag: <remarks> Adds information about a type, supplementing the information specified with <summary>.
Tag: <returns> Describes the return value from a method.
Tag: <seealso> Specifies the text to appear in the See Also section.
Tag: <value> Describes a property.
Tag: <summary> Describes a type or a type member.
The content for the <summary> tag should be short and discrete when describing the purpose of a type or type member. To provide further details, use the <remark> tag.
Where angle brackets need to appear in the text of a documentation comment, use < ( < )and > ( > ). For example: /// <summary cref=”C < T >”>
Example 1:<summary> and <history> tags:
///\<summary\>
/// Defines an exception that can be raised during security operations.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= =====================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public class SecurityException : SystemException
{
}
Example 2:<summary>, <param>, <remarks>, <returns> tags:
///\<summary\>
/// Create a new student record.
///\</summary\>
public void Create()
{
}
///\<summary\>
/// List student records that match criteria.
///\</summary\>
///\<param name="pageIndex"\>Page index\</param\>
///\<param name="pageSize"\>Page size\</param\>
///\<returns\>Collection of Student objects\</returns\>
public Collection\<Student\> List(
Int16 pageIndex,
Int16 pageSize)
{
}
///\<summary\>
/// Retrieve a lookup description for a given code and type.
///\</summary\>
///\<param name="lookupType"\>Lookup type\</param\>
///\<param name="lookupCode"\>Lookup code\</param\>
///\<param name="messages"\>Message collection\</param\>
///\<returns\>Lookup description string\</returns\>
///\<remarks\>
/// The \<paramref name="lookupType"\>lookupType\</paramref\> can receive
/// a lookup type value from the database or a stored procedure name.
///\</remarks\>
internal static string GetLookupDescription(
string lookupType,
string lookupCode,
MessageCollection messages)
{
}
Block tags
Block tags are typically used inside <remarks> and <example> sections to add structure to the text:
Tag: <c> Indicates that text within a description should be marked as code.
| Tag: <list> | Specifies a definition list or table. |
Tag: <para> Enables adding of structure to the text. Used inside a tag such as <summary>, <remarks>, or <returns>.
Inline tags
Tag: <c> Indicates that text within a description should be marked as code.
Tag: <paramref> Creates a reference to a parameter. For example: <paramref name=”size”/>
Tag: <typeparamref> Creates a reference to a type parameter. For example: <typeparamref name=”T”/>
Tag: <see>
Specifies a link from within text.
For example: <see cref=”System.Console.WriteLine(System.String)”/>
Coding standards
General coding standards
| Rule | Do Not |
|---|---|
| 1. | Don’t use ‘magic numbers’ (literal numbers or other value types). Literals should be replaced with constants which should be named to clearly indicate the significance of the number or string value. |
Code formatting
To improve the readability of code, DET has adopted the following general standards:
| Rule | Do: Indentation and Spacing |
|---|---|
| 1. | Code is indented two spaces, or by using the tab key with tabs set to two spaces in the IDE, to follow the logical structure, so that all statements in the same logical level are in the same indentation. |
| 2. | Comments should be indented with the same number of spaces as the associated code. |
| 3. | Indent code inside of a control structure (For..Next, If..Then, etc.). |
| 4. | Curly braces ( {} ) should be indented to the same level as the code outside the braces. |
| Rule | Do: General Formatting |
| 5. | Use white space sensibly to enhance readability of the code. |
| 6. | Break long statements and lists of parameters (more than two or three) into multiple lines. |
| 7. | Curly braces ( {} ) should be on a separate line and not in the same line as if, for, etc. |
| 8. | Use a single blank line within methods, to separate logical blocks of code. |
| 9. | Use a single blank line to separate the variable declarations from the code. |
| 10. | Use a single space before and after each operator and brackets. |
| Rule | Do: Grouping |
| 11. | Group related statements and processing together. For example, group the variable declarations together, group constants together etc. |
| 12. | Make use of regions to group similar code together. Some common regions include: Declarations, Public Properties, Public Methods, Private Methods, Page Events. |
| Rule | Do Not |
|---|---|
| 13. | Don’t have more than one statement on a single line. |
| 14. | As a general rule-of-thumb, don’t code excessively long lines. |
| 15. | Don’t use end-of-line comments. |
An example follows.
Example: Grouping by regions(comments removed to reduce size):
public class Student
{
#region Declarations
private const string ENTITY\_NAME = "Student";
#endregion
#region Public Properties
private Int32 \_id;
public Int32 ID
{
get { return \_id; }
set { \_id = value; }
}
private string \_lastName;
public string LastName
{
get { return \_lastName; }
set { \_lastName = value; }
}
#endregion
#region Public Methods
public void Create()
{
}
public void Update()
{
}
#endregion
}
Control structure issues
General control structure rules:
| Rule | Do |
|---|---|
| 1. | Use True and False in expressions, rather than 1 and 0. |
| 2. | Nested statements should be simplified by re-testing part of the conditional, converting to If-Then-Else or Case statements, or moving nested code into its own routine. |
| 3. | If a routine has a decision count of more than 10, consider redesigning it. Deep nesting makes a routine hard to understand. A decision could be considered commands such as: If….else, switch, case, catch, while, do, etc. As the decision count increases, so does the complexity. Complex code leads to less stability and maintainability - the more complex the code, the higher risk of defects. |
Use of Var
| Rule | Do |
|---|---|
| 1. | Use var when using LINQ queries to project more complex types without having to define your own type. |
| Rule | Do Not |
| 2. | Don’t use var to infer the type being assigned to variables. Instead, explicitly declare the concrete type for all variables. |
Example:
// Find any properties on the parent object that implement the IValidatableEntity interface.
var properties = instance.GetType().GetProperties()
.Where(a =\> a.PropertyType.IsClass)
.Where(a =\> a.PropertyType.GetInterfaces().Contains(typeof(IValidatableEntity)));
String concatenation
| Rule | Do |
|---|---|
| 1. | Use the StringBuilder class to concatenate strings (unless a small number of them are involved in which case the standard String.Concat / ‘+’ operator may improve readability without sacrificing performance). |
Example:
System.Text.StringBuilder roleList = new StringBuilder();
foreach (string role in userRoles)
{
roleList.Append(String.Concat(role, ","));
}
Coding namespaces
| Rule | Do |
|---|---|
| 1. | Declare namespaces directly after the using statements within a class. |
Example:
using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Text;
using OneFramework;
using OneFramework.Web;
using OneFramework.AppName;
namespace OneFramework.Web.Forms
{
}
namespace OneFramework.AppName.BusinessLogic
{
}
See also:
- Section 3.3.3. Naming Namespaces
- Section 3.3.1. General Naming Standards
Coding classes
| Rule | Do |
|---|---|
| 1. | Declare each class in a separate code file. |
| 2. | Include a comment header for each class. At a minimum, include <summary> and <history> sections. |
Example:
///\<summary\>
/// Class for Student entity.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ==================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public class Student
{
}
///\<summary\>
/// Base class for exception translation.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ==================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public abstract class BaseExceptionTranslator
{
}
///\<summary\>
/// Data access class for Student entity.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ===================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
internal static classStudentDA
{
}
///\<summary\>
///Collection class for collection of student results.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ===================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public class StudentResultCollection: ICollection
{
}
Coding properties
| Rule | Do |
|---|---|
| 1. | Declare member variables at the top of the class. |
| 2. | Include a comment header for each property. |
Example:
private string \_lastName;
private DateTime \_dateOfBirth;
///\<summary\>
/// Last name of student.
///\</summary\>
public string LastName
{
get { return \_lastName; }
set { \_lastName = value; }
}
///\<summary\>
/// Student's date of birth.
///\</summary\>
public DateTime DateOfBirth
{
get { return \_dateOfBirth; }
set { \_dateOfBirth = value; }
}
Coding methods
| Rule | Do |
|---|---|
| 1. | Do one thing per method. Every method should have a single, precise purpose. |
| 2. | Keep methods short. Avoid too many lines of code in each method - the suggested limit is 100 lines. |
| 3. | Use comment* header for each method: |
| a | Use a <summary> section to describe the method. |
| b | If parameters are used, add a <param> tag to describe each parameter. |
| c | If the method returns a value, include a <returns> tag. |
| d | Use a <remarks> section to convey more details about the method. |
* For more information on using and formatting comments see Section 4, Commenting
Example:
///\<summary\>
/// Create a new student record.
///\</summary\>
public void Create()
{
}
///\<summary\>
/// List student records that match criteria.
///\</summary\>
///\<param name="pageIndex"\>Page index\</param\>
///\<param name="pageSize"\>Page size\</param\>
///\<returns\>Collection of Student objects\</returns\>
public Collection\<Student\> List(
Int16 pageIndex,
Int16 pageSize)
{
}
///\<summary\>
/// Retrieve a lookup description for a given code and type.
///\</summary\>
///\<param name="lookupType"\>Lookup type\</param\>
///\<param name="lookupCode"\>Lookup code\</param\>
///\<param name="messages"\>Message collection\</param\>
///\<returns\>Lookup description string\</returns\>
///\<remarks\>
/// The \<paramref name="lookupType"\>lookupType\</paramref\> can receive
/// a lookup type value from the database or a stored procedure name.
///\</remarks\>
internal static string GetLookupDescription(
string lookupType,
string lookupCode,
MessageCollection messages)
{
}
Coding parameters
| Rule | Do |
|---|---|
| 1. | Declare parameters on a separate line. Exceptions to this rule include: |
| a | Where minimal parameters are used and the declaration can fit on one line. |
| b | Automatically generated code: for e.g. Page_Load(object sender, EventArgs e) |
| 2. | Add a <param> tag for each parameter declaration in the method comment header. |
| Rule | Do Not |
| 3. | Don’t reserve parameters for future use. If more data is needed in the next version, a new overload can be added. |
**Example:**
///\<summary\>
/// Update student details.
///\</summary\>
///\<param name="id"\>Unique student identifier\</param\>
///\<param name="lastName"\>Last name\</param\>
///\<param name="firstName"\>First name\</param\>
///\<param name="dateOfBirth"\>Date of birth\</param\>
///\<param name="yearLevel"\>Year level\</param\>
public void Update(
Guid id,
string lastName,
string firstName,
DateTime dateOfBirth,
Int16 yearLevel)
{
}
Coding interfaces
| Rule | Do |
|---|---|
| 1. | Use a comment header for interface class declarations. |
Example:
///\<summary\>
/// Lookup interface.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ===================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public interface ILookup
{
}
///\<summary\>
/// Lookup class that implements ILookup interface.
///\</summary\>
///\<history\>
/// Who Date Task# Description
/// ======== ========== ========= ===================================
/// [dafra0] 09/10/2007 1 Created.
///\</history\>
public class Lookup : ILookup
{
}
Coding constants
| Rule | Do |
|---|---|
| 1. | Expose constants publicly if needed. There is no need to use a property to access the constant value. |
| 2. | Use comment header for each constant. Exceptions to this rule include constants declared in the local scope of a method or property. |
Example:
///\<summary\>
/// Entity name.
///\</summary\>
private const string ENTITY\_NAME = "Student";
///\<summary\>
/// Session timeout limit in minutes. Currently set to 60.
///\</summary\>
internal const Int32 SESSION\_TIMEOUT\_MINUTES = 60;
///\<summary\>
/// Mime type - plain text.
///\</summary\>
public const string MIME\_TYPE\_TEXT = "text/plain";
///\<summary\>
/// Mime type - html.
///\</summary\>
public const string MIME\_TYPE\_HTML = "text/html";
///\<summary\>
/// Mime type - gif image.
///\</summary\>
public const string MIME\_TYPE\_GIF = "image/gif";
///\<summary\>
/// Create method.
///\</summary\>
public void Create()
{
const Int16 DEFAULT\_YEAR\_LEVEL = 1;
}
Coding enumerations
| Rule | Do |
|---|---|
| 1. | Define enumerated values using an enum if they are used in a parameter, property or return value. |
| 2. | Provide a value of 0 for simple enumerations: |
| a | If possible, this option should be named None. |
| b | If not possible, set 0 as the most used enum option (the default). |
| 3. | Use Int32 as the underlying type of an enum. Exceptions to this rule include: |
| a | Where the enum represents flags, and there are more than 32 flags. |
| b | Where the enum may grow to 32 flags in the future. |
| c | Where the type needs to be different from int for backward compatibility. |
| 4. | Use the Flags custom attribute if the numeric values are meant to be bitwise ORed together. |
| 5. | Use Flags enums only if the value can be completely expressed as a set of bit flags. |
| 6. | Provide comment headers for each enum declaration and enum option. |
| Rule | Do Not |
| 7. | Don’t use enums for open sets (such as operating system version). |
Example:
///\<summary\>
/// Enum for primary colours.
///\</summary\>
///\<remarks\>
///\</remarks\>
public enum PrimaryColour
{
///\<summary\>
/// Red.
///\</summary\>
Red = 1,
///\<summary\>
/// Green.
///\</summary\>
Green = 2,
///\<summary\>
/// Blue.
///\</summary\>
Blue = 3
}
///\<summary\>
/// Bitwise enum operator to determine file status.
///\</summary\>
[Flags]
public enum FileStatus
{
///\<summary\>
/// No status.
///\</summary\>
None = 0,
///\<summary\>
/// File is open.
///\</summary\>
Open = 1,
///\<summary\>
/// File is in edit mode.
///\</summary\>
Edit = 2,
///\<summary\>
/// File is saved.
///\</summary\>
Save = 4,
///\<summary\>
/// File is closed.
///\</summary\>
Close = 8,
///\<summary\>
/// File is corrupt.
///\</summary\>
Corrupt = 16,
///\<summary\>
/// File is busy.
///\</summary\>
Busy = 32,
///\<summary\>
/// File status is Good (Open, Edit, Save or Close state).
///\</summary\>
Good = Open | Edit | Save | Close,
///\<summary\>
/// File status is Bad (Corrupt or Busy state).
///\</summary\>
Bad = Corrupt | Busy
}
Coding events and delegates
| Rule | Do |
|---|---|
| 1. | Use two parameters named sender and e: |
| a | The sender parameter represents the object that raised the event, and this parameter is always of type object, even if it is possible to employ a more specific type. |
| b | The state associated with the event is encapsulated in an instance e of an event class. Use an appropriate and specific event class for its type. |
| 2. | In general, provide a protected method called Onxxx on types with events that can be overridden in a derived class. This method should only have the event parameter: e, because the sender is always the instance of the type. |
| 3. | Add a comment header for event/delegate declaration. |
Example:
///\<summary\>
/// Refresh Cache Delegate.
/// Called to refresh the object before it is cached.
///\</summary\>
///\<param name="args"\>Parameters required for the refresh action
///\</param\>
///\<returns\>Object to be cached, once refreshed\</returns\>
public delegate objectRefreshCacheCallback(object[] args);
///\<summary\>
/// Event handler that is executed when item has changed.
///\</summary\>
///\<param name="sender"\>\</param\>
///\<param name="e"\>\</param\>
public delegate voidChangedEventHandler(object sender, EventArgs e);
Coding local and member variables
| Rule | Do |
|---|---|
| 1. | Declare variables as strongly typed. |
| 2. | Declare each variable on a new line. |
Example:
public class Student
{
private Int16 \_defaultYearLevel = 1;
private Decimal \_defaultPaymentAmount = 1500.00;
///\<summary\>
/// Return the number of classes for a given student.
///\</summary\>
public Int32 GetNumberOfClasses()
{
Int32 numberOfClasses = 0;
string studentName = String.Empty;
…
}
}
Coding using statements
| Rule | Do |
|---|---|
| 1. | using statements should be listed, in the following order: 1) System namespace. 2) OneFramework namespace. 3) Application-specific namespace. |
| 2. | using statements should be in alphabetical order within the list groups shown above. In the IDE, right-click a using statement and select Organize Usings > Remove and Sort to remove unused usings and sort the rest. |
Example:
using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Text;
using OneFramework;
using OneFramework.Web;
using OneFramework.AppName;
Coding If-Then-Else statements
| Rule | Do: General Rules |
|---|---|
| 1. | Ensure the nominal path through the code is clear. |
| 2. | Ensure the normal case follows the If rather than the Else. |
| 3. | Ensure all cases are covered. |
| Rule | Do: Formatting |
| 4. | Always include curly braces around If statements, even if they aren’t required (i.e. a single statement after the If or Else statement). |
| 5. | Place curly braces on the next line after the If statement. |
| Rule | Do: Tests |
| 6. | Encapsulate complicated tests in boolean function calls. |
| 7. | Test the most common cases first. |
| 8. | For multiple tests: |
| a | Start each test on a new line, unless all tests can fit on one line. |
| b | Enclose each test in brackets, to specify the order/precedence of operations. |
| c | Include the “and” or “or” operator separating multiple tests on a new line in front of the new test. |
| d | Use a default clause in the last Else in a chain of If-Then-Else to trap errors. |
| Rule | Do Not |
| 9. | Don’t include statements on the same line as the If statement. |
Example:
// Check if user has access to the operation.
if (HasAccessToOperation(this.Context.User))
{
// Test if user is in admin or teacher role.
if ((IsUserInRole(this.Context.User, ROLE\_ADMIN))
|| (IsUserInRole(this.Context.User, ROLE\_TEACHER)))
{
// Perform additional processing...
}
}
else
{
// If current user or user identity is null.
if ((this.Context.User == null) && (this.Context.User.Identity == null))
{
// Perform additional processing...
}
}
Coding switch (case) statements
| Rule | Do |
|---|---|
| 1. | Use meaningful names for cases. |
| 2. | Format case statements consistently with the formatting of other control structures. |
| 3. | Ensure actions for each case are simple. |
| 4. | Ensure the use of default clauses is legitimate. |
| 5. | Use default clauses to detect and report unexpected cases. |
| 6. | Use the default clause in a case statement to trap errors. |
Example:
switch (status)
{
case (UserStatus.Active):
// User is active.
break;
case (UserStatus.Rejected):
case (UserStatus.Temporary):
// User is rejected or temporary.
break;
default:
// User is inactive (default).
break;
}
Coding loops
| Rule | Do |
|---|---|
| 1. | Ensure the initialisation code is directly before the loop. |
| 2. | Ensure the loop performs only a single function. |
| 3. | Use variables to save important loop-index values, rather than using the loop index outside the loop. |
| 4. | Ensure loops are short enough to view all at once, where possible. |
| 5. | Ensure long loops are especially clear or well documented. |
| 6. | Ensure loops contain a specific termination condition. |
| 7. | Ensure a loop’s termination condition is obvious. |
| Rule | Do Not |
| 8. | Don’t nest beyond three levels, unless this can’t be avoided. |
6. Code analysis
Code Analysis provides an executable set of rules that can be checked during a build to ensure standards and practices are being adhered to during development.
OneFramework has customised the Microsoft All Rules rule set, and projects can use these customised rules to ensure conformance to DET standards.
The customised file can be found in the installed directory of OneFramework under References OneFramework.ruleset.
OneFramework also has additional references and checklists available to support these C# Coding Standards and help projects comply with DET coding standards:
- OneFramework Code Analysis Naming Rules and Guidelines
- OneFramework DET Code Analysis Rules
- OneFramework C# Code Review Checklist
- OneFramework Presentation Layer Code Review Checklist
- OneFramework Business Layer Code Review Checklist
- OneFramework Data Access Layer Code Review Checklist
All documents are available from the OneFramework OnePortal site
Appendix A: Creating and using custom dictionaries
A.1 Creating a custom dictionary
To create a custom dictionary:
- Create a file named CustomDictionary.xml.
- Define custom words using the following XML structure:
<?xml version=”1.0” encoding=”utf-8” ?> <Dictionary> <Words> <Unrecognized> <Word></Word> </Unrecognized> <Recognized> <Word></Word> </Recognized> <Deprecated> <Term PreferredAlternate=””></Term> </Deprecated> <Compound> <Term CompoundAlternate=””></Term> </Compound> <DiscreteExceptions> <Term></Term> </DiscreteExceptions> </Words> <Acronyms> <CasingExceptions> <Acronym></Acronym> </CasingExceptions> </Acronyms> </Dictionary>
A.1.1 Element descriptions
Element: Unrecognized Description and example:
- Exclude a term from the list of terms that code analysis identifies as correctly spelled.
- Not case-sensitive.
<Dictionary>
<Words>
<Unrecognized>
<Word>kilometer</Word>
</Unrecognized>
…
Element: Recognized Description and example:
- Include a term in the list of terms that code analysis identifies as correctly spelled.
- Not case-sensitive.
<Dictionary>
<Words>
…
\ Recognized>
<Word>kilometre</Word>
</Recognized>
…
Element: Deprecated Description and example:
- Include a term in the list of terms that code analysis identifies as deprecated.
- To include a suggested alternate term in the warning, specify the PreferredAlternate attribute. Leave the attribute value empty if you don’t want to suggest an alternate.
- The deprecated term is not case-sensitive.
- The PreferredAlternate attribute value is case-sensitive. Use PascalCase for compound alternates.
<Dictionary>
<Words>
…
<Deprecated>
<Term PreferredAlternate=”LogOn”>login</Term>
</Deprecated>
…
Element: Compound Description and example:
- Include a term in the list of terms that code analysis identifies as a compound word and to specify the correct casing of the term.
- In the CompoundAlternate attribute, specify the individual words that make up the compound term by capitalising the first letter of the individual words.
- The specified compound word is automatically added to the DiscreteExceptions list.
- The deprecated term is not case-sensitive.
- The CompoundAlternate attribute value is case-sensitive. Use PascalCase for compound alternates.
<Dictionary>
<Words>
…
<Compound>
<Term CompoundAlternate=”CheckBox”>checkbox</Term>
</Compound>
…
Element: DiscreteExceptions Description and example:
- Exclude a term from the list of terms that code analysis identifies as a single, discrete word.
- Not case-sensitive.
<Dictionary>
…
<DiscreteExceptions>
<Term>checkbox</Term>
</DiscreteExceptions>
…
Element: Acronyms Description and example:
- Include an acronym in the list of terms that code analysis identifies as correctly spelled, and to indicate how the acronym is checked under casing rules for compound words.
- Case-sensitive.
<Dictionary>
… <Acronyms>
\ CasingExceptions>
<Acronym>DET</Acronym>
</CasingExceptions>
</Acronyms>
</Dictionary> |
A.2 Adding a custom dictionary to project(s)
To add a custom dictionary to a single project, or use the dictionary across multiple projects:
-
To add a dictionary to a single project: a. In Solution Explorer, right-click on the project name and select Add Existing Item b. In the Add Existing Item dialog, browse to and select the CustomDictionary.xml file - you may need to choose All Files (*.*) in the file types drop down list.
-
To add a dictionary to be used by multiple projects: a. In the Add Existing Item dialog, browse to and locate the CustomDictionary.xmlfile - you may need to choose All Files (*.*) in the file types drop down list. b. Move to the Add button and click the down arrow. c. Select Add As Link from the drop-down menu.
- Back in Solution Explorer, right-click the CustomDictionary.xml file and select Properties.
- Go to the Properties pane, move to the Build Action list, and select CodeAnalysisDictionary.
- Go to the Copy to Output Directory list and select Do not copy.
Appendix B: NET Framework Namespaces
Microsoft.CSharp Microsoft.JScript Microsoft.VisualBasic Microsoft.Vsa Microsoft.Win32 System System.CodeDom System.CodeDom.Compiler System.Collections System.Collections.Specialized System.ComponentModel System.ComponentModel.Design System.ComponentModel.Design.Serialization System.Configuration System.Configuration.Assemblies System.Configuration.Install System.Data System.Data.Common System.Data.Odbc System.Data.OleDb System.Data.OracleClient System.Data.SqlClient System.Data.SqlServerCe System.Data.SqlTypes System.Diagnostics System.Diagnostics.SymbolStore System.DirectoryServices System.Drawing System.Drawing.Design System.Drawing.Drawing2D System.Drawing.Imaging System.Drawing.Printing System.Drawing.Text System.EnterpriseServices System.EnterpriseServices.CompensatingResourceManager System.EnterpriseServices.Internal System.Globalization System.IO System.IO.IsolatedStorage System.Management System.Management.Instrumentation System.Messaging System.Net System.Net.Sockets System.Reflection System.Reflection.Emit System.Resources System.Runtime.CompilerServices System.Runtime.InteropServices System.Runtime.InteropServices.CustomMarshalers System.Runtime.InteropServices.Expando System.Runtime.Remoting System.Runtime.Remoting.Activation System.Runtime.Remoting.Channels System.Runtime.Remoting.Channels.Http System.Runtime.Remoting.Channels.Tcp System.Runtime.Remoting.Contexts System.Runtime.Remoting.Lifetime System.Runtime.Remoting.Messaging System.Runtime.Remoting.Metadata System.Runtime.Remoting.Metadata.W3cXsd2001 System.Runtime.Remoting.MetadataServices System.Runtime.Remoting.Proxies System.Runtime.Remoting.Services System.Runtime.Serialization System.Runtime.Serialization.Formatters System.Runtime.Serialization.Formatters.Binary System.Runtime.Serialization.Formatters.Soap System.Security System.Security.Cryptography System.Security.Cryptography.X509Certificates System.Security.Cryptography.Xml System.Security.Permissions System.Security.Policy System.Security.Principal System.ServiceProcess System.Text System.Text.RegularExpressions System.Threading System.Timers System.Web System.Web.Caching System.Web.Configuration System.Web.Hosting System.Web.Mail System.Web.Security System.Web.Services System.Web.Services.Configuration System.Web.Services.Description System.Web.Services.Discovery System.Web.Services.Protocols System.Web.SessionState System.Web.UI System.Web.UI.Design System.Web.UI.Design.WebControls System.Web.UI.HtmlControls System.Web.UI.WebControls System.Windows.Forms System.Windows.Forms.Design System.Xml System.Xml.Schema System.Xml.Serialization System.Xml.XPath System.Xml.Xsl
Appendix C: common programming keywords
Note: A keyword search facility is available at: http://www.reservedwordsearch.com
A
Abstract
AddHandler
AddressOf
Alias
And
AndAlso
Ansi
As
Assembly
Assert
Auto
B
Base Bool Boolean Break ByRef Byte ByVal
C
Call Case Catch CBool CByte CChar CDate CDbl CDec Char Checked CInt Class CLng CObj Const Continue CShort CSng CStr CType
D
Date Decimal Declare Default Delegate Dim DirectCast Do Double
E
Each Else ElseIf End Enum Erase Error Eval Event Exit Explicit Extends Extern ExternalSource
F
False Final Finalize Finally Fixed Flag Flags Float / Float[n] For Foreach Friend Function
G
Get GetType GoSub Goto Guid
H
Handles
I
If Implements Implicit Import Imports In Inherits Instanceof Int / Int[n] Integer Interface Internal IntPtr Is
L
Let Lib Like Long Loop
M
Me Mod Module MustInherit MustOverride MyBase MyClass
N
Namespace Native New Next Not Nothing NotInheritable NotOverridable Null
O
Obj Object On Operator Option Optional Or OrElse Out Overloads Overridable Override Overrides
P
Package ParamArray Params Pointer Preserve Private Property Protected Ptr Public
R
RaiseEvent Readonly ReDim Ref Region REM RemoveHandler Resume Return
S
Sbyte
Sealed
Select
Set
Shadows
Shared
Short
Signed
Single
Sizeof
Stackalloc
Static
Step
Stop
Strictfp
String
Struct
Structure
Sub
Super
Switch
Synchronized
SyncLock
T
Then This Throw Throws To Transient True Try Type TypeOf
U
UByte UInt / UInt[n] UInteger UIptr Ulong UPointer UPtr Unchecked Unicode Unsafe Unsigned Until Ushort Using
V
Var Variant Virtual Void Volatile
W
WChar When While With WithEvents WriteOnly
X
Xor