Start Omhoog Guidelines Begrippen

Capitalization Styles

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.

Naming Guidelines


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
    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
    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
    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.


  • 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
    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)
    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 Guidelines

    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.
    GetType(typeName As String)As Type
    Format(format As String, args() As object)As String
    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 _