Use properties where appropriate

In most cases, properties represent data and methods perform actions. Properties are accessed like fields, which makes them easier to use. A method is a good candidate to become a property if one of these conditions is present:

• The method takes no arguments and returns the state information of an object.
• The method accepts a single argument to set some part of the state of an object.

A method has a name that starts with Get, takes no parameters, and returns a value that's not an array.

By default, this rule only looks at externally visible methods, but this is configurable.

To fix a violation of this rule, change the method to a property.

Suppress a warning from this rule if the method meets one of the following criteria. In these situations, a method is preferable to a property.

• The method can't behave as a field.
• The method performs a time-consuming operation. The method is perceivably slower than the time that is required to set or get the value of a field.
• The method performs a conversion. Accessing a field does not return a converted version of the data that it stores.
• The Get method has an observable side effect. Retrieving the value of a field does not produce any side effects.
• The order of execution is important. Setting the value of a field does not rely on the occurrence of other operations.
• Calling the method two times in succession creates different results.
• The method is static but returns an object that can be changed by the caller. Retrieving the value of a field does not allow the caller to change the data that's stored by the field.
• The method returns an array.