Performance Optimization Techniques With Coding Standard Best Practices In C#

Nowadays, performance and security are very crucial aspects of business prospects. If your product is not good in performance and not secure as well, then you are certainly going to lose your reputation. Performance and security give a positive impact towards,

Customer trust
High volume of business
Reputation etc.

Because these two aspects are the keys to any software product, we can achieve these both in many ways. In this article, I am going to discuss the best practices of coding standards.

Let's say, we have a business requirement where every developer can write code in their own way to meet the business requirement. But what makes the difference between you and them? As per my understanding, in most cases, the developer thinks only from one angle which is the functional requirement to meet the business requirement, but remember, that's not enough. The real developer should think of multiple aspects before jumping into the implementation including both functional and non-functional aspects. Here, I mentioned one aspect, the non-functional requirement. This aspect plays a vital role along with the functional requirement. Non-functional requirement includes the following:

Security
Performance
Scalability
Extendability
User friendliness etc

As a developer, we have to consider the above points along with functional requirements. Going forward, I will show you a few of the best coding practices.

Coding standards help in writing easily understandable code and maintaining consistency. I highly recommend to every software programmer or developer to follow the coding guidelines to help improve the readability of your source code and make software maintenance easier. I have listed a few best coding practices which provide:

Great performance
Minimized complexity
Easier maintainability etc.

Given below are a few of the best coding standard practices:

Assignments should not be made from within sub-expressions
Files should not have too many lines of code (maximum 1000 lines in a namespace)
Methods should not be too complex (Default value is 10).
Lines should not be too long (maximum length is 200)
Methods should not have too many parameters (Default value is 7 )
switch statements should not have too many case clauses (Default value is 30)
Control flow statements do, while, switch, if, foreach, for and try should not be nested too deeply (Default value is 3)
Expressions should not be too complex
Generic exceptions should not be ignored
Types should be named in Pascal case
switch case clauses should not have too many lines
Classes should not have only private constructors
async and await should not be used as identifiers
Boolean checks should not be inverted
Use break statements only with switch cases, don't use except switch cases.
TODO tags should be handled and add summary to every method in the file and Methods should not be empty
Enumerations Flags with zero-value members should be named None
Fields that are only assigned in the constructor must be readonly.
For Parameters with [DefaultParameterValue] attributes should also be marked with [Optional]
Empty default clauses in a switch should be removed

Assignments should not be made from within sub-expressions

Assignments within sub-expressions are hard to identify and make the code less readable. From the below table, we can observe that the preferable column contains == operator. It is also a common mistake to write "=" when "==" was meant to be written. Ideally, the expressions should not have side-effects.

Example

Reason: Assignments within sub-expressions are hard to identify and make the code less readable.
Complexity: Major
Files should not have too many lines

Problem
A source file containing too many lines of code with too many responsibilities causes difficulty to understand it and makes it harder to maintain.

Solution
It's advised to break down the responsibilities into smaller pieces as methods which focus on well-defined tasks. Then, merge them at last in calling the method. Those smaller files will not only be easier to understand but easier to test also.

Default value: 1000
Complexity: Major
Methods should not be too complex

Problem
Cyclomatic complexity of a function should not exceed a defined threshold. If that exceeds the limit, it causes:
• Poor performance
• Takes lot of time to execute the code which results in performance impact
• Difficult to maintain the code
• Difficult to understand

Solution
We can use Task Parallel Library (TPL) to overcome such complex code execution.

Default value: 10
Complexity: Major
Lines should not be too long

Problem
Having too long lines of cod so that it scrolls horizontally, that makes it difficult to understand the complete code.

Solution
It's advised to split the lengthy line of code into some pieces which makes it easier to understand.

Maximum length: 200
Complexity: Minor
Methods should not have too many parameters

Problem
A long parameters list creates a new structure to contain so many parameters.

Solution
Encapsulate multiple parameters into a single object.

Ex: Instead of String fname, String lname, String address, String contact-number etc. into a object type, let's define them in a Person object containing all these fields and pass this object type as a methods input parameter.

Default value: 7
Complexity: Major
SWITCH statements should not have too many CASE clauses

Problem
Usually, it is an attempt to map two sets of data. The real map structure will be more readable and maintainable and it should be used instead.

Solution
CASE clause content should be minimized by dividing into methods

Maximum: 30
Minimum: 3
Mandatory: default case
Complexity: Major
Control flow statements IF, FOR, FOREACH, DO, WHILE SWITCH and TRY should not be nested too deeply

Problem
Nested flow statements or multiple conditions cause the complex code which is hard to understand. Also, multiple nested flow statements or multiple conditional statements cause the performance issues.

Solution
Replace control flow statement conditions into multiple methods (splitting condition based code into multiple methods), and call them in the targeted area.

Maximum: 3
Complexity: Major
Expressions should not be too complex

Problem
The complexity of an expression is decided by the number of ||, && and condition? if True: if false operators it contains.

Solution
Breakdown multiple conditions into methods and call them in the targeted area. Sample code is, as shown below:

Complexity: Major
Generic exceptions should not be ignored

If exception occurs in your code, then it's bad practice to simply ignore it. Instead, it is good to handle it properly and if you need to, you log them.

Solution:

Complexity: Major
Types should be named in Pascal case

As per coding standards types (structure, class), name should be in Pascal case.

Complexity: Minor
SWITCH case clauses should not have too many lines

Problem
CASE clause contains too many statements and causes difficulty in readability.

Solution
The content of CASE clause should be moved in a dedicated method, as shown below:

Complexity: Major
Default threshold: 5
Classes should not have only PRIVATE constructors

Problem
A class having only a private constructor cannot be instantiated and it seems to be worthless code.

Solution
Class should contain public constructors as well. Sample code is, as the following:

Complexity: Major
ASYNC and AWAIT should not be used as identifiers

async and await are reserved keywords. So, we should not use them for variable names in order to avoid the confusion. It is advisable not to use these keywords.

Complexity: major
Boolean checks should not be inverted

Problem
Using inverted Boolean checks is costly and complex.

Solution
Instead, we should use the opposite Boolean comparison. Sample code is written below:

Complexity: Minor
Break statements should not be used except for switch cases

Break statement makes it difficult to read the code. Most preferable, every loop should have a single termination point. And, it's advised to use close braces for every condition and also, use else part for every if condition.

Complexity: Minor
TODO tags should be handled and add summary to every method in the file and methods should not be empty

If any method is empty or something you want to implement at a later point of time, then in such cases, use TODO tags within the method; which states that something needs to be implemented in TODO tags area. Outside of the methods, write some summary by stating the actual use of the method, so that, at a later point when you forgot, if you filter with TODO keyword, it will give you the filtered result and there it will remind you to write something. And by seeing the summary part, everyone can easily understand the purpose of the method.

Complexity: info
Flags enumerations zero-value members should be named NONE

We should use None flag for 0 value while defining ENUM and we should make a standard practice to maintain the consistency. Sample code is, as below:

Complexity: Minor
Fields that are only assigned in the constructor should be read-only

By the name itself, we can say that only read-only members should be assigned in a class constructor. If member variables are not declared as read-only whereas we are assigning their values in a class constructor, then unnecessarily we are creating confusion. So, to avoid such confusion, if you want to assign field value in a class constructor, then mark those fields as read-only, otherwise don't use fields inside class constructor which are not marked as read-only.

Complexity: Minor
Parameters with [DefaultParameterValue] attributes should also be marked with [Optional]

If the caller provides the value for a parameter at any cost, then it's useless to set the default value for a parameter. The DefaultParameterValue must be used in combination with Optional because DefaultParameterValue is non-usable without optional.

Complexity: Minor
Empty DEFAULT clauses in a SWITCH should be removed

If you use default clause in switch case, then it should contain an appropriate action. If not, then there is no meaning of using default clause.

Complexity: Minor

Fiends, if you use the above coding standards, then really you will get a lot of benefits, as listed below:
- Application performance will be improved.
- Code maintainability will be easier.
- Code re-usability can be acheived.
- Easy to identify bugs.
- Code complexity can be reduced, and much more...

24 Comments

Join the conversation! Your thoughts help the community grow.

phakawan wongpetanan9y ago
It is really good and very useful.
Tunde John9y ago
On declaring class constructor as private, I tend to disagree as this technique is mostly used in Singleton or Factory patterns especially when you don't want the class instantiated directly
Subash10y ago
Good share sir
Shamim Uddin10y ago
Nice
Delpin Susai Raj10y ago
Good one
Anu V10y ago
Nice..
Ritesh Singh10y ago
Nice post dear
Suraj Pant10y ago
Nice article
Ravi Kandel10y ago
Nice
Rakesh10y ago
Good share
Anupam Singh10y ago
Great share specially points mentioned in coding standard practices with examples.
Kaviya Balasubramanian10y ago
Useful Post
Guest User10y ago
Wow great post! many take aways from this article
Venkat10y ago
Nice post
Subash10y ago
Nice share
Christopher logue10y ago
Nice post, Thanks
ritik kataria10y ago
Simple and roburst post
Ramesh Palaniappan10y ago
Nice Article.
Prasanna Murali10y ago
Nice post
Vignesh Mani10y ago
Nice one
Tk Mahanta10y ago
Very Nice
Manas Mohapatra10y ago
Very informative
Bhuvanesh Mohankumar10y ago
Good one
Humayun Kabir Mamun10y ago
Nice...