Methods

  • DO use PascalCasing for all method names, including local functions.

  • DO name methods and local functions using verbs or verb-object pairs.

    Name a method or local function using a verb like Show or a verb-object pair such as ShowDialog. A good name should give a hint on the what of a member, and if possible, the why.

    Also, don’t include And in the name of a method or local function. That implies that it is doing more than one thing, which violates the Single Responsibility Principle.

  • ✅ The method name should have meaningful name so that it cannot mislead names. The meaningful method name doesn’t need code comments.

  • DO name members similarly to members of related .NET Framework classes.

    .NET developers are already accustomed to the naming patterns the framework uses, so following this same pattern helps them find their way in your classes as well. For instance, if you define a class that behaves like a collection, provide members like Add, Remove and Count instead of AddItem, Delete or NumberOfItems.

  • DO postfix asynchronous methods with Async or TaskAsync.

    The general convention for methods and local functions that return Task or Task<TResult> is to postfix them with Async. But if such a method already exists, use TaskAsync instead.

  • ✅ The method or function should have only single responsibility (one job). Don’t try to combine multiple functionalities into single function.

    public class Employee
    {
    	// Correct
    	public void Update(Address address)
    	{
    	}
    
    	public void Insert(Address address)
    	{
    	}
    
    	// Avoid
    	public void Save(Address address)
    	{
    		if (address.AddressId == 0)
    		{
    		}
    		else
    		{
    		}
    	}
    }
    
  • DO split your logic in several small and simple methods.

    If methods are too long, sometimes it is difficult to handle them. It is always better to use a number of small methods based upon their functionality instead of putting them in a single one. If you break them in separate methods and in future you need to call one part, it will be easier to call rather than replicating the code. Also, it is easier to do unit testing for the small chunks rather than a big code. So, whenever you are writing a piece of code, first think of what you want to do. Based upon that, extract your code in small simple methods and call them from wherever you want. In general, a method should never be more than 10-15 lines long.

Learn More