10 Golden rules of development

 The 10 rules every developer should follow while development

Referred Link - https://app.pluralsight.com/course-player?clipId=031aa5d9-fb16-4c05-9843-83b937e2fc2c 

Rule 10: Avoid Regions Regions are used in c# to separate various blocks of code in c#. In general regions are used to navigate easily in a large class. If we carefully observe, these regions hide ugly code in a very complex and large class. Instead of using regions, it is advisable to refactor and move the region specific logic to a separate class

Rule 09: Use Exceptions for errors

public bool Login(string userName, string password)
{
if(String.IsNullOrEmpty(userName))
{
return false;
}
//..
return true;
}
COPY

In above method, if the username is empty, the method returns false. This can be misleading because, if the username is empty, the login is not even verified and hence it is ideal if we throw an exception instead. The exception would ensure that no further functionality is executed because username is empty

Rule 08: Avoid Boolean parameters for public methods

Instead of passing plain boolean values as parameters, create two separate methods, one for execution of positive flow and another for negative flow. This would ensure we are creating better readable code

Rule 07: Avoid Too many parameters

For readability purposes, if we encounter methods with more than 3 parameters, think of encapsulating those parameters into a separate method

Rule 06: Warnings are Errors

Today's warning is tomorrows error. Developers tend to ignore warnings and sooner or later they turn into errors. It is recommended to enable the setting to treat warnings as errors in visual studio as below

Rule 05: Encapsulate complex expressions

if(account.Balance>0 && !account.IsVIP && account.DueDate > CurrentDate)
{
// do something
}
COPY

We encounter expressions like above in every day. This is a maintenance nightmare. Instead encapsulate these expressions into account class as below

if(account.IsPastDue)
{
// do something
}
COPY

Rule 04: Try to avoid multiple exit points from method

Instead of returning from various if .. else statements, it is recommended to have one entry and one exit point to every method.

Instead of below code

if(account.Balance<5000){
return false;
}
else if(account.IsPastDue)
{
return false;
}
else if(account.IsVip)
{
return false;
}
return true;
COPY

use below code

var isValid=true;
if(account.Balance<5000){
isValid =  false;
}
else if(account.IsPastDue)
{
isValid = false;
}
else if(account.IsVip)
{
isValid = false;
}
return isValid;
COPY

Above code has only one entry point and one exit point and makes it much more maintainable

Rule 3: Try to avoid comments Comments are mainly used to describe some logic or code. If your code is not self explanatory, refactor and make it meaningful. Comments become stale very quickly and developers tend to forget changing comments whenever they change code. Hence comments not only create maintenance problems but some times can cause confusion if they become stale

Rule 2: Keep methods short If your method is doing too many things, split them. In a general rule of thumb, if the method is having greater than 20 lines of code, it is already too big.

Rule 1: Keep classes short Classes should only do one and only one thing. If you find class doing 2 things, refactor it