

Identifier |
Case |
Example |
Class |
Pascal |
AppDomain |
Enum type |
Pascal |
ErrorLevel |
Enum values |
Pascal |
FatalError |
Event |
Pascal |
ValueChange |
Exception class |
Pascal |
WebException
Note Always ends with the suffix Exception.
|
Read-only Static field |
Pascal |
RedValue |
Interface |
Pascal |
IDisposable
Note Always begins with the prefix
I .
|
Method |
Pascal |
ToString |
Namespace |
Pascal |
System.Drawing |
Parameter |
Camel |
typeName |
Property |
Pascal |
BackColor |
Protected instance field |
Camel |
redValue
Note Rarely used. A property is preferable to
using a protected instance field.
|
Public instance field |
Pascal |
RedValue
Note Rarely used. A property is preferable to
using a public instance field.
|
PasalCasing
The first letter in the identifier and the first letter of each subsequent
concatenated word are capitalized.
Class Naming Guideline
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
[C#]
public
class
FileStream
public
class
Button
public
class
String
|
Interface Naming Guidelines
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
[C#]
public
interface
IServiceProvider
public
interface
IFormatable
|
Attribute Naming Guidelines
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
[C#]
public
class
ObsoleteAttribute{}
|
Enumeration Type Naming Guidelines
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, but use a plural
name for Enum types that are bit fields.
Always add the FlagsAttribute to a bit field Enum
type.
Static Field Naming Guidelines
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.
It is recommended that you use static properties instead of public
static fields whenever possible.
Method Naming Guidelines
Use verbs or verb phrases to name methods.
Use
Pascal case.
RemoveAll()
GetCharArray()
Invoke()
|
Property Naming Guidelines
Use a noun or noun phrase to name properties.
Use
Pascal case.
Do not use Hungarian notation.
Consider creating a property with the same name as its underlying
type. For example, if you declare a property named Color, the type of
the property should likewise be
Color. See the example later in this topic.
The following code example illustrates correct property naming.
Public Class
SampleClass
Public
Property BackColor
As Color
' Code for Get and
Set accessors goes here.
End
Property
End
Class
[C#]
public
class
SampleClass
{
public
Color BackColor
{
// Code for
Get
and Set
accessors goes here.
}
}
|
Event Naming Guidelines
Use
Pascal case.
Do not use Hungarian notation.
Use an EventHandler
suffix on event handler
names.
Specify two parameters named sender and e. The
sender parameter represents the object that raised the event. The
sender parameter is always of type object, even if it is
possible to use a more specific type. The state associated with the
event is encapsulated in an instance of an event class named e.
Use an appropriate and specific event class for the e parameter
type.
Name an event argument class with the EventArgs
suffix.
Consider naming events with a verb. For example, correctly named
event names include Clicked, Painting, and DroppedDown.
Use a gerund (the "ing" form of a verb) to create an event name that
expresses the concept of pre-event, and a past-tense verb to represent
post-event. For example, a Close event that can be canceled
should have a Closing
event and a
Closed
event. Do not use the
BeforeXxx
/AfterXxx
naming pattern.
Do not use a prefix or suffix on the event declaration on the type.
For example, use Close
instead of
OnClose
.
In general, you should 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.
The following example illustrates an event handler with an
appropriate name and parameters.
Public Delegate
Sub
MouseEventHandler(sender As
Object, e
As
MouseEventArgs)
[C#]
public
delegate
void MouseEventHandler(object
sender, MouseEventArgs e);
|
camelCasing
The first letter of an identifier is lowercase and the first letter of each
subsequent concatenated word is capitalized.
Parameter Naming GuidelinesIt 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.
GetType(typeName
As
String)As
Type
Format(format
As
String, args()
As
object)As
String
[C#]
Type
GetType(string
typeName)
string
Format(string
format, object[]
args)
|
- we spreken af (class design guideline) een query ahv een ReadOnly Property
te definiëren indien de implementatie weinig cpu-tijd absorberende operties
verricht (bv gewoon een veldwaarde wordt opgeleverd) en een query ahv een
function te definiëren indien de uitvoer van implementatie meer cpu-tijd zal
absorberen (bv bij het eerst berekenen van een waarde voor deze kan worden
opgeleverd)
- de naming guidelines -die we hanteren- raden aan voor identifiers van
datatypes en publieke members PascalCasing te gebruiken (te starten met een
hoofdletter), voor private members, lokale variabelen (of parameters) gebruiken
we dan camelCasing (starten met een kleine letter), voor velden een prefix _