Asim

This is Asim, a full stack web developer, a Toastmaster, and Ninja too. Passionate about building and learning new technologies. Any problem? wanna fight? then write your anger at: me@asimplify.com +(92)345 5306849

Categories
Tags

Top 10 Rules For High Standard C# Programming – ASIMplify

Top 10 Rules For High Standard C# Programming – ASIMplify

Hi,
Whether you are writing code in C# or any other programming language, you may rush towards the implementation of problem you have to solve and if you are an organization where your Team Leads don’t have time to review your code or if your Team Lead is not that much good, who actually concentrate on whether problem is solved or not. No matter what’s your standard of coding is. Then you are in the same boat like I am. You have to listen to each and every comment of your team members and follow them quickly regardless of the approach you will follow, you must have to solve the problem on time and sometimes before time.

But, the question is. Do you want to follow blindly? Do you want to get straight into the solution rather than giving some time and think about the approach you will choose? and the main question is, Do you want to spoil yourself?

We must have to be curious and dedicated to learning new things and learn to follow good clean coding approaches if we want to build something so if someone sees our work they appreciate our effort.

So, for that, I am happy to share some good practices that I strive to follow in my daily and freelance job regardless of the time constraint (some times I don’t :p )

So let’s start from top to bottom.

Coding Standard Rule # 10 – To Avoid Regions

Regions are a feature of Visual Studio that allows you to Surround blocks of code, doesn’t have to be a method, could be multiple methods and to put those blocks into regions that you can then give a name to and then you can collapse a region. There are also keyboard shortcuts to expand and collapse a specific region or expand and collapse all regions. Presumably, regions exist because it makes it easier to navigate around a large file. And because most coding standards will specify that you only have one class in a file, that means regions can be used to break up and navigate a large class and therein lies the problem.

Regions are normally used to hide ugly code or classes that have exploded in size and also in responsibility. The code on the screen is typical of what it seems for regions.

If your class is doing too many things and you have put regions to clean them up, then it’s time to sit back relax and think about if you can break your class into sub classes and make them clean rather than using regions to cleanse the dirt.

Coding Standard Rule # 9 – Use Exceptions For Errors

I have developed so much dirty code in my professional career. For Example

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

That’s what I wrote a year back, You see the problem in the above function. If you pass an empty string to this function it will return False. rather than giving you the detailed error of what you have done wrong it will just return false

That’s the badly implemented functions must return proper exceptions on errors so the caller knows what went wrong and so (s)he will fix accordingly. Throwing proper exception will give insight about the problem.

Coding Standard Rule # 8 – Avoid Boolean Parameters


...
public void WriteFile(byte[] contents, bool flush){
//...
}
...

If you look into the above code, there is parameter flush type bool.

Let’s suppose caller have to call that method with some arguments.

...
WriteFile(data, false)
...

What if you have exposed this method as an API endpoint? how does the caller know what this bool is all about?
Caller may think, Is this false is for not saving data? or if I make it true will I get the bitcoins?

You see, they don’t have real insight about that boolean value.

What’s the good approach is that, make two endpoints for flushing and not flushing the stream. like:

...
public void WriteFile(byte[] contents){
WriteFile(data, false)
}
...

...
public void WriteFileWithFlush(byte[] contents){
WriteFile(data, true)
}
...

Making two functions with clear signature gives caller clear idea what the function will do. Not by putting bool in the parameters.

Coding Standard Rule # 7 – Avoid Too many Parameters

Consider below function for login, do you think it looks great?

...
function bool Login(string userName, string password, bool isPersist, string ipAddress, string dateTime){
//...
}
...

Ah, one parameter is good, two is good too, three is even better but after four and so on that looks messy you must have to avoid it by making a class and passing the object of the class containing all the relevant data in properties of that class.

...
public class LoginModel{
public string UserName{get; set;}
public string Password{get; set;}
public string IsPersist{get; set;}
public string IPAddress{get; set;}
}
...

Login(LoginModel loginModel)
...

Coding Standard Rule # 6 – Treat Warnings as Errors

You may have heard or said to some one “I don’t care about warnings”.
But as a good developer, you must have to care about the warnings as well.

Turn on the build feature so that VisualStudio treat each warning as an error. you will learn from it and you will write clean codes by doing that.

Visual Studio will suggest very good standard if you mark to treat warnings as errors.

Coding Standard Rule # 5 – Encapsulate Complex Expressions

Always try to make things simple and readable.

...
if(youAreTired && workDone && LoggedHours < 4 || attendanceMark > 6 && month != 8 && year == 2017){

}
...

If you try to read the above line of it’s hard to understand what will be the true input. And if you try to understand that you are tired and you haven’t logged the working hours and your attendance is short too you can leave the office on time.

You can encapsulate the whole expression in simplified form and make it like this below:

...
if(office.IsDayPassed){
}
...

That looks cool and easy to read.

Coding Standard Rule # 4 – Try To Avoid Multiple Exists

...
If(youAreTired){
return false;
}else if(!isWorkDone){
return false;
}else if(youLikeCoffee){
return false;
}else{
return true;
}
...

You see in the above checks you have four return statements, it looks messy and you must try and avoid multiple exit points.

Let’s make it one.

...
var isValid= true;
If(youAreTired){
isValid = false;
}else if(!isWorkDone){
isValid = false;
}else if(youLikeCoffee){
isValid = false;
}else{
isValid = true;
}
return isValid;
...

Now you can see you just have one entry point and only one exit point.

Coding Standard Rule # 3 – Try To Avoid Comments

That’s the debatable topic, I had some serious fights whether we should write hell lot of comments for each line of code or not.
My point always was and will be it looks very dirty, as complier has nothing to do with your comments, and your code must be expressive, your naming conventions must be that much expressive so that no one wants to read what you are trying to do.

If you write comments in each line, then you must have to think there are lots of improvement from naming conventions to the implementation you have to make.

Coding Standard Rule # 2 – Keep Methods Short

Methods should be with in the same screen not more than that. Or if you say in terms of a number of lines that it must depend on the situation and nature of the function but you must not go with more than 40 to 50 lines of the method. If your method is taking more lines then sit back relax have a cup of coffee and see how can you divide that method into a number of methods to avoid crowdedness.

Coding Standard Rule # 1 – Keep Classes Small

Same goes for the classes if your class is that much large that if one starts understanding it then (s)he must have to scroll several whiles to gets to the bottom and if they have to go through that again he may leave your job and put the resignation.

So for the classes, you must have to think about how can you minimize the class up to the certain level it reflects the roles and the responsibilities of classes. You must have to figure out in the Object Oriented Programming.

That’s all from my side, if you find any ambiguity and if you want to teach me please write a comment below I will respond ASAP.

I hope you adopt some of these rules too because I strongly believe they have helped me in getting job done in effecient and effective manner.

Stay Blessed, Have a good day. Cheers 😉

Comments

comments

Asim
asimaslam.kh@gmail.com
  • ali imran

    some time we don’t void comments , specially when you are working with large teams. comments help other developers easy to understand the code. By the way nice information #asimplify

  • Asim

    Thank You, Ali that’s what other taught us the whole time. But the emphasis on the well-structured code is made by those who really want to learn, just for the developer who actually reads that not for the computer to understand. The computer can understand any crap we write, but not humans.
    So if you feel that you need to write comments for each line you have written, then you must have to rethink about the naming conventions you named your properties your function your class and other stuff. So any other developer will understand it at one glance, and most importantly they feel glad to read your code.
    Happy Coding 😉

Please wait...

Have courage to interact?

Any problem? Wanna fight? Get yourself subscribe first.