C# Best Practices - Creating Good Methods

How to Define a Method

Identify the problem => Define the single purpose => Specify the inputs and outputs => State any assumptions => Consider the error that could occur

Build a Method

Signature

public bool PlaceOrder(Product product, int quantity)

Optional accessibility modifier (Default is private)

Return type (void if no value)

Method name

Parameter list (Empty parenthesis if no parameters)

XML Document Comment

Use ///

Summary for method purpose

param for a description of each parameter

Signature Best Practices

Do:

Use a verb

Define the most restricted accessibility possible

Keep the number of parameters to a minimum

Define an XML document comment

Avoid:

Vague terms

Abbreviations

Conjunctions (and/or)

Inconsistent naming

Method Body

public bool PlaceOrder(Product product, int quantity)
{
    // Guard Clause (garbage in,not garbage out)
    if (product == null) throw new ArgumentNullException(nameof(product));
    if (quantity <= ) throw new ArgumentOutOfRangeException(nameof(quantity));
}

Best Practices

Do:

Keep methods short (less than 20 lines)

Use white space

Use guard clause

Return an expected result (Use an object to return multiple values)

Implement exception handling

Avoid:

void methods

Property or Method

Property example:

ProductName, Description, InventoryCount?, SuggestedPrice?

Method example:

PlaceOrder(), CalculateInventoryCount()?, CalculateSuggestedPrice()?

Property:

Does it describe data?

Does it execute quickly?

Method:

Does it describe processing?

Does it produce side effects?

Does it require parameters?

Method Overloading

public bool PlaceOrder(Product product, int quantity)

public bool PlaceOrder(Product product, int quantity, DateTimeOffset deliveryBy)

public bool PlaceOrder(Product product, int quantity, DateTimeOffset deliberyBy, string instructions)

public void PlaceOrder(Product prouct, int quantity) ** Not a valid overloading

Best Practices

Do:

Keep the number of parameters to a minimum

Keep the order of the parameters consistent

Define a XML document comment for each overload

Consider optional parameters

Avoid:

Confusing overloads

Overloads that differ in purpose

(Example: OrderItems. One overload get the ordered items, the second overload orders a set of items)

Duplicating code

Method chaining

public OperationResult PlaceOrder(Product product, int quantity)
{
    return PlaceOrder(product, quantity, null, null);
}

public OperationResult PlaceOrder(Product product, int quantity, DateTimeOffset? deliverBy)
{
    return PlaceOrder(product, quantity, deliverBy, null);
}

public OperationResult PlaceOrder(Product product, int quantity, DateTimeOffset? deliverBy)
{
    // All of the code here
}

Method Chaining Best Practices

Do:

Use to minimize repeated code in method overloads

Consider optional parameters

Avoid:

If it adds complexity

Method Overriding

We can override ToString() for each entity class to make debug easy

FAQ

1.What's the primary purpose of a method?

To implement the logic required for specific behavior or functionality in a class

2.What is the difference between a parameter and an argument?

A parameter is part of the method signature

An argument is part of the method call

3.What is method overloading?

Methods with the same name and purpose but different signatures.

4.What is method chaining?

One method overload calls another overload to prevent repeated code.

5.When is it the best to use method overloading vs. method overriding?

Use overloading when one method requires multiple signatures. Such as GetCustomer(id) to get a customer by id and GetCustomer(name) to get a customer by name.

Use overriding when replacing a method defined high up the object hierarchy. Such as replacing the ToString() method.