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;
}
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
}
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
}
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;
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;
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
Posts
