Miscellaneous Design Guidelines

Throw exceptions rather than returning some kind of status value (HTA1200)

A code base that uses return values to report success or failure tends to have nested if-statements sprinkled all over the code. Quite often, a caller forgets to check the return value anyway. Structured exception handling has been introduced to allow you to throw exceptions and catch or replace them at a higher layer. In most systems it is quite common to throw exceptions whenever an unexpected situation occurs.

Provide a rich and meaningful exception message text (HTA1202)

The message should explain the cause of the exception, and clearly describe what needs to be done to avoid the exception.

Throw the most specific exception that is appropriate (HTA1205)

For example, if a method receives a null argument, it should throw ArgumentNullException instead of its base type ArgumentException.

Don’t swallow errors by catching generic exceptions (HTA1210)

Avoid swallowing errors by catching non-specific exceptions, such as Exception, SystemException, and so on, in application code. Only in top-level code, such as a last-chance exception handler, you should catch a non-specific exception for logging purposes and a graceful shutdown of the application.

Properly handle exceptions in asynchronous code (HTA1215)

When throwing or handling exceptions in code that uses async/await or a Task remember the following two rules:

• Exceptions that occur within an async/await block and inside a Task’s action are propagated to the awaiter.
• Exceptions that occur in the code preceding the asynchronous block are propagated to the caller.

Always check an event handler delegate for null (HTA1220)

An event that has no subscribers is null. So before invoking, always make sure that the delegate list represented by the event variable is not null. Invoke using the null conditional operator, because it additionally prevents conflicting changes to the delegate list from concurrent threads.

event EventHandler<NotifyEventArgs> Notify;

protected virtual void OnNotify(NotifyEventArgs args)
{
	Notify?.Invoke(this, args);
}

Prefix events with the word ‘On’ (HTA1225)

For example, the protected virtual method for an event named TimeChanged is named OnTimeChanged.

Use a protected virtual method to raise each event (HTA1226)

Complying with this guideline allows derived classes to handle a base class event by overriding the protected method. With respect to the previous guideline, the name of the protected virtual method should be the same as the event name prefixed with On.

Note: Derived classes that override the protected virtual method are not required to call the base class implementation. The base class must continue to work correctly even if its implementation is not called.

Consider providing property-changed events (HTA1230)

Consider providing events that are raised when certain properties are changed. Such an event should be named PropertyChanged, where Property should be replaced with the name of the property with which this event is associated

Note: If your class has many properties that require corresponding events, consider implementing the INotifyPropertyChanged interface instead. It is often used in the Presentation Model and Model-View-ViewModel patterns.

Don’t pass null as the sender argument when raising an event (HTA1235)

Often an event handler is used to handle similar events from multiple senders. The sender argument is then used to get to the source of the event. Always pass a reference to the source (typically this) when raising the event. Furthermore don’t pass null as the event data parameter when raising an event. If there is no event data, pass EventArgs.Empty instead of null.

Exception: On static events, the sender argument should be null.

Use generic constraints if applicable (HTA1240)

Instead of casting to and from the object type in generic types or methods, use where constraints or the as operator to specify the exact characteristics of the generic parameter. For example:

class SomeClass
{
}

// Don't
class MyClass
{
	void SomeMethod(T t)
	{
		object temp = t;
		SomeClass obj = (SomeClass) temp;
	}
}

// Do
class MyClass where T : SomeClass
{
	void SomeMethod(T t)
	{
		SomeClass obj = t;
	}
}

Generally evaluate the result of a LINQ expression before returning it (HTA1250)

Consider the following code snippet

public IEnumerable<GoldMember> GetGoldMemberCustomers()
{
	const decimal GoldMemberThresholdInEuro = 1_000_000;

	var query =
		from customer in db.Customers
		where customer.Balance > GoldMemberThresholdInEuro
		select new GoldMember(customer.Name, customer.Balance);

	return query;
}

Since LINQ queries use deferred execution, returning query will actually return the expression tree representing the above query. Each time the caller evaluates this result using a foreach loop or similar, the entire query is re-executed resulting in new instances of GoldMember every time. Consequently, you cannot use the == operator to compare multiple GoldMember instances. Instead, consider explicitly evaluating the result of a LINQ query using ToList(), ToArray() or similar methods.

There are exceptions to this rule in cases where the evaluation of each element is expensive and the caller may abort the enumeration early. In that case it may be best to return an IEnumerable and leave the caller to decide whether to evaluate the entire enumeration or not. If re-enumerating the method return will result in re-executing the logic creating the enumeration then this should be clear in the method documentation.

Do not use this and base prefixes unless it is required (HTA1251)

In a class hierarchy, it is not necessary to know at which level a member is declared to use it. Refactoring derived classes is harder if that level is fixed in the code.