Login | Register
My pages Projects Community openCollabNet

Style Guidelines
for
Advanced Unit Testing Project

Introduction

I don't want to be too heavy handed with style guidelines, so hopefully everyone can live with them.  Since there is already a considerable code base, I'd rather not adopt a style that requires a significant amount of refactoring, and I certainly don't want to mix styles.  So here we go...

Document Style

The following describes general document styles.

Tabs

Set tabs to 4 spaces (the default)

"Keep tabs" is preferred but optional

Margins

80 column margins can definitely be exceeded for readability.  I realize some people like to print code, but forcing a margin, splitting lines, etc., for the sake of printing is not desirable.

File Names

Filenames start with an upper case letter (Pascal case)

Code Style

The following conventions come from http://www.irritatedvowel.com/Programming/Standards.aspx, .Net Standards and Best Practices.  As we're already following them (or nearly so!), I see no reason to change.

Type Standard Example
Namespaces Pascal Case, no underscores. Use CompanyName.TechnologyName as root. If you don't have a company, use your domain name or your own initials. Note that any acronyms of three or more letters should be pascal case (Xml instead of XML) instead of all caps. AppliedIS.TimeCard.BusinessRules
IrritatedVowel.Controllers
PeteBrown.DotNetTraining.InheritanceDemo PeteBrown.DotNetTraining.Xml
Assemblies If the assembly contains a single name space, or has an entire self-contained root namespace, name the assembly the same name as the namespace. AppliedIS.TimeCard.BusinessRules.dll
IrritatedVowel.Controllers.dll
Classes and Structs Pascal Case, no underscores or leading "C" or "cls". Classes may begin with an "I" only if the letter following the I is not capitalized, otherwise it looks like an Interface.  Classes should not have the same name as the namespace in which they reside. Any acronyms of three or more letters should be pascal case, not all caps.  Try to avoid abbreviations, and try to always use nouns. Widget
InstanceManager
XmlDocument
Collection Classes Follow class naming conventions, but add Collection to the end of the name WidgetCollection
Delegate Classes Follow class naming conventions, but add Delegate to the end of the name WidgetCallbackDelegate
Exception Classes Follow class naming conventions, but add Exception to the end of the name InvalidTransactionException
Attribute Classes Follow class naming conventions, but add Attribute to the end of the name WebServiceAttribute
Interfaces Follow class naming conventions, but start the name with "I" and capitalize the letter following the I IWidget
Enumerations Follow class naming conventions. Do not add "Enum" to the end of the enumeration name. If the enumeration represents a set of bitwise flags, end the name with a plural. SearchOptions
Functions and Subs Pascal Case, no underscores except in the event handlers.  Try to avoid abbreviations.  Functions and subs must differ by more than case to be usable from case-insensitive languages like Visual Basic .Net VB: Public Sub DoSomething(...)

C#: public void DoSomething(...)

Properties and Public * Member Variables Pascal Case, no underscores.  Try to avoid abbreviations.   Members must differ by more than case to be usable from case-insensitive languages like Visual Basic .Net. VB: Public Property RecordID As Integer

C#: public int RecordID

Parameters Camel Case.  Try to avoid abbreviations.  Parameters must differ by more than case to be usable from case-insensitive languages like Visual Basic .Net. VB: ByRef recordID As Integer

C#: ref int recordID

Procedure-Level Variables Camel Case VB: Dim recordID As Integer

C#: int recordID ;

Class-Level Private and Protected Variables Camel Case with Leading Underscore. In VB.Net, always indicate "Protected" or "Private", do not use "Dim". VB: Private _recordID As Integer

C#: private int _recordID ;

Controls on Forms Modified Hungarian Using .Net Class Names txtUserID, lblHeader, lstChoices, btnSubmit

* Public class-level variables are generally frowned upon.  It is considered to be a better practice to use property procedures to provide read and/or write access to a private member variable.  If you must expose a member variable to other classes using "Public", follow the property naming conventions.

You Can find the standards for publically exposed classes/properties etc at MSDN.  If you want to run a tool to validate your code for public standards and required practices, download FXCop.

NOTE: If you use strongly-typed datasets, you will find it makes a lot of sense to follow the PascalCase naming convention with your database tables and fields as well.  That is because strongly-typed datasets are simply classes with properties for table field names.

Brace Style

A brace appears on a new line at the same indent level as the preceding line.  Code within the brace is indented one level.

Example:

for (int i=0; i<10; i++)
{
    // more code
}