Methods

Methods

Not much is significantly different between methods in the managed world and methods in the unmanaged world. The most notable points are the following:

• Determining when you should implement a method instead of a property

• Naming conventions for method names and method parameter names

Implementing Methods Instead of Properties

In general, methods represent actions and properties represent data. However, in some situations, it is not appropriate to implement properties. Because property accessors are equivalent to methods, you should instead implement methods in those situations. Here are some examples:

• If a property accessor has observable side effects, implement a method instead of a property.

• If the implementation of a property is considerably more expensive than that of a field, implement a method instead. When you expose a property, you suggest to users that making frequent calls to it is acceptable. When you implement a method, you suggest to users that they should save and reuse a returned value if they repeatedly need it.

• If some properties require a user to set them in a predefined order, implement those properties as methods. In general, you should design your components so that properties can be set in any order.

• If you need a write-only property, implement a method instead.

Examples of these cases and additional ones appear in the white paper ".NET Framework Design Guidelines ”Writing Class Libraries for the .NET Framework," on MSDN.

Naming Guidelines for Methods and Method Parameters

To ensure that your naming scheme for methods conforms to that of the .NET Framework, follow these guidelines:

• Use method names that consist of verbs or verb phrases that indicate the task accomplished ”for example, Add , Dispose , and Verify .

• Use Pascal casing for method names ”for example, CreateChildControls and SaveViewState .

You should also follow the .NET Framework naming guidelines for parameter names. It is imperative to follow the guidelines for method parameter names because parameters are displayed in the designer when visual design tools provide context-sensitive IntelliSense and class-browsing functionality. These are the guidelines:

• Use descriptive parameter names. They should be descriptive enough so that, in most scenarios, the parameter name and type are sufficient to determine the parameter's meaning. Descriptive parameter names provide valuable information to the user.

• Use camel casing for parameter names. This means using lowercase for the first word in the parameter name and capitalizing the first letter of each subsequent word in the name ”for example, level , minimumLevel , and maxHits .

• Use a name based on the parameter meaning rather than its type. For example, if a parameter is of type integer, a name such as count is much more informative than a name such as int .

• Do not prefix parameter names with Hungarian notation.