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 IntegerC#:
ref int recordID |
| Procedure-Level Variables |
Camel Case |
VB: Dim recordID As IntegerC#: 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 IntegerC#:
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
}