This article provides a broad overview of review process for the code written in C# using Visual Studio 2015 and also uncovers best practices for code review. Code Review is a very important part of any developer’s life. Code review is a technique which allows another developer (not necessarily working in same team or same feature within a team) to go over-n-through your code line-by-line and identify areas for improvement or point out holes.  Hence, code review is a process and not a technology. However, there are some tools available (covered later in this article) which can enable a developer to write good quality code.


There are numerous guidelines and best practices software development teams follow and depend on. This article will uncover most of those but it may not cover all the best practices around code review. However, I want to assure you that all the guidelines mentioned below will help any individual to practice and apply good coding principles and perform a quality code review.

Is it must to have my code, reviewed by other dev?

Well, you must. But it depends on your team’s development methodology and ALM (Application Lifecycle Management) tool settings. There are ways to by-pass the code review by simply just not doing it and straight checking-in the code. It’s not recommended though.

What if my code is not reviewed?

It’s hard to say, but at times and in some cases it might cause serious issues and raise concern for the whole team. For instance, a condition check is missed, or null is not handled properly or not all error situations are being handled by your exception handling block. Well, these examples might sound very simple and most of the developers do write defensive code and cover such aspects. But what code review can also provide value towards is your “design”, “techniques”, “patterns”, “approach” etc.

How to find a code reviewer

I have worked in various team settings and work environments. Many times I have been invited to perform a code review for a developer who is not part of my team or rather I am not part of their team. But what I admire and appreciate here is the fact; that someone reached out to another dev in case of their team’s developer is either not available or busy with critical production issue etc. Such mindset empowers the team to deliver the best written code.

Let’s Begin with Best Practices of code Review

Here, I am going to list out some areas which are critical from code review perspective. I tried to highlight the core best practices which are must in any code review. I have seen many times that in a code review developers are more focused to look for code design patterns or some areas in code review and then try to convince

1- Project and File names

Many times developer’s only focus on code, but in my view your Project name, file name etc. also matters a lot. It’s not sufficient to deliver well written functional code; a well-defined project and file name is equally important and brings a lot of clarity by offering a sense of purpose being served by solution, project or a file. For instance see the solution and project name in as shown in the image below.

Figure-1: Properly named Solution and Project

2- Always begin from the top

Before you really start scanning through the code blocks/statements in a class (.cs) file; I would recommend that you must 1st look at the “using” statements in any .cs file. I have personally observed that many times developers add numerous “using” statements while trying various code blocks to achieve the functionality. But once that functionality is accomplished; many developers tend to forget about cleaning up references of those “using” statements which are no longer needed now and must be removed. Visual Studio 2015 show unused using statements in grey color which can be safely removed as shown in the image below.

Figure-2: Un-used using statements are grayed out by default in Visual Studio 2015

3-  Sort all the using statements

Usual development practice is that we keep adding new using statements at the end of previous ones, for instance as shown in the image below.

Figure-3: Newly added using statements

Let’s assume that code is consuming all of the added using statements, but the issue is that these are not sorted. One of the coding best practices is to Sort all using statements. To sort using statements right-click in code editor windows and click on “Organize Usings” then click on “Sort Usings”.

Figure-4  Sort Usings option in Visual Studio 2015

After performing the “Sort Usings” all the using statements will be alphabetically sorted (this is the only order A – Z) and will be arranged as shown in the image below.

Figure-5 Alphabetically Sorted Using statement

4- Don’t just ignore warnings

As a developer we are more focused on compilation errors and want to see that project/solution build successfully. For instance, consider the code as shown in the image below.

Figure-6 sample code

This is a very simple code and project will build successfully without any compilation errors. However, as you can see that “j” is used nowhere in the code and so this will cause a warning; which many developers doesn’t seem to care about. In my view and as many software companies including many Microsoft teams I have worked with enforce 0 warnings policy before check-in. Hence, it is very important to look in detail at the “Error List” View menu à Error List, and then observe Warning Tab and must try to have that also show “0 Warning” just like we always work to only see “0 Errors”.

 Figure-7 Error List, highlighting warning in the code

5-  Code Consistency

One very important quality of well written code is “Consistency”. I.e. stick to one style. Let’s say that you want to declare an integer variable and it’s obvious that different teams and developers will have different coding guidelines. Many times developers ignore this and code has scattered instances of types/keywords Int32 or int and String or string, this demonstrates that code consistency is violated. However, using mixed statements will successfully compile the code but makes your code base completely in-consistent. 

Figure-8 Code consistency violation

6-  Do care for Null all the times

Null has catastrophic impact on your code functionality. Simply a null check ignored and you will face the consequences. This is why many developer productivity tools like Re-Sharper prompt for any potential “NullReferenceException” which can be triggered from your code. Make sure that all your if/else do take enough care of null and have guard(s) in place, most of the times IsNullOrEmpty or IsNullOrWhiteSpace will come really handy.

7-  Dead code

Many times I have seen that as a developer we are mostly interested in our own code; to be specific, code we are writing. At times we do observe a block of code which is commented for long, but we don’t seem to care, but why not?  Well, in my view there are two reasons for this. First, I don’t care as long as my code works. Second, I am working in an agile team and I am committed to finish my task in committed timelines. First one is an attitude problem, second is timeline and hours remaining to complete the work. But both can do one thing for sure. Open an item in Technical Debt backlog with details to have that file cleaned up.

8-  Naming Convention

All developers today are well aware of Camel and Pascal casing and when to use one over the other. For instance variable and parameter names must follow Camel casing and for class, function, and method names Pascal casing must be used. Make sure this basic principle is applied consistently.

9-  Code Readability

Many times code is written in a way that anyone can hardly make sense out of it. I.e. all code is so jumbled up and one line after the other that it’s barely readable. Make sure that code has proper Single line spacing wherever applicable between the code blocks.

 10-Handling Unmanaged Resources 

Even though .NET Framework takes good care of Memory management via GC (garbage collection) but there are limitations on what all garbage items and from where those can be collected and what not. Many times, it’s wise to handle cleaning of expensive resources like File I/O handles, connections, Network resources, etc. by yourself. Such items can be disposed of once their usage is over and this can be done using the “using” block for unmanaged code, if you want to automatically handle the disposing of objects once they are out of scope.  Another good place to handle such code is finally block for example, File I/O operation to read a file as shown in the image below.

Watch my YouTube channel video on FIle I/O here:

Figure-9 Handling unmanaged resources by .NET’s StreamReader

11-    Write Defensive Code

.NET Exception Handling is the key to write defensive code and protect your application against any runtime anomalies. Three magic words to solve most of your problems are try/catch and finally. Proper implementation and usage of Exception Handling and logging any exception messages and details can add a lot of value to application in terms of application monitoring and troubleshooting.

12-    Declare access specifiers explicitly

C# .NET has default scope defined for various types for instance a variable is private by default and so in a class we like to write just “int i” but it’s more appropriate to be declarative and instead write it as “private int i”.

Do you know what default scope of a class is in C #? Watch my YouTube channel video here 

13- Self Documenting code

Many times developers do follow naming convention (camel or pascal etc.) but the given names to variables, methods, functions and class etc. are not meaningful at all. Hence, at times developers write long code comments to describe what is the  purpose of each function or variable for instance. In my view, giving “self-describing” names will add a lot of value and also save developer’s time in documenting the code; as many software teams have a practice of writing comment above each line of code to explain the objective of code below. For instance, instead of “int age;” you may want to declare “int studentAge;”. Similarly, instead of just writing a function with name “GetData()” it will be preferred and more helpful to say “GetStudentsReportData()”. Similar techniques can also be applied to class names, functions and Unit Tests etc. But in case of unit tests, name(s) might get really lengthy, but this is totally fine and acceptable. Hence, a unit test method name “TestSuccessWithOneStudentRecordAddedToDb” will be much preferred than just saying “TestOneRecordData”.


Above mentioned code review guidelines are light weight, easy to look for and easy to apply techniques with larger impact on any code base.  Mostly it has been evident that simple things are either ignored or not cared about. These best practices can be added up with more guidelines or in combination with other techniques as applicable. Happy Coding…

I am now also contributing to Microsoft Channel9.
More videos are in production and will be available soon.


 Related Articles:

Inside Out: TDD using C#

Visual Studio and .NET Unit Test Framework

Unit Test Automation with Visual Studio


Unit Tests play an important role in delivering high quality software solutions. An ideal unit test is a piece of code (automated test) written by a developer which exercises a small but specific area of code functionality to ensure that it works as expected.

Why Unit Test

According to the Test Triangle, in a software project the largest number of tests must be Unit Tests. Because multiple individual Unit Tests exercises small units of functionality which spans over entire various areas of functionality offered by the software solution.


Unit Test Check-List

While writing Unit Test(s) following points must be considered and followed by the Developers and SDETs.




Self-Describing Names

Unit Test method names must be Self-Describing and Pascal case.  For example choose Add_New_Customer_With_Valid_AcccountNumber over AddCustomer_with_validAcc or addCustomer etc.Also focus on naming style, keep the naming style consistent across all the tests methods and test.

   [ ]

A3 (Arrange, Asset, Act)

Make sure that all the Test Methods are designed around Arrange, Act and Assert.If required Refactor your code to fall into these three sections.

   [ ]

Test Happy and Sad Path

The unit test should cover all possible scenarios and strive for high code coverage and ensuring good quality metrics. Unit Test methods must exercise all possible use case scenarios to test the input validations, interactions, errors messages, edge cases and exceptions etc.

   [ ]

Make use of Attributes

Use Test Framework provided Attributes like :

[TestCategory(“<describe if its Unit or Integration Test>”)]

[TestCategory(“<Which section of the application is being tested>”)]

[Priority(n), TestCategory(“<define if it’s Gated or not-Gated build Tests>”)]


[Owner(“<who wrote this test>”)]

   [ ]

Have least number of asserts per test (if applicable)

A good Unit test should only have limited # of assert statements. It should unit test the very functionality, as indicated in its descriptive name.A well-defined Unit Test should contain only one assert statement per test and must not try to exercise all the validation/boundary checks etc. by multiple Assert() in one Unit Test method. .

   [ ]

Keep assert messages descriptive

Use descriptive messages to improve readability of code and the build log.Assert.IsTrue(customer.IsExist,”The Customer is not found in the Database”);

   [ ]

Unit != Integration

There is a very fine line between Unit and Integration, if you happen to go beyond what your function is supposed to be doing then you are not writing a Unit Test. I.e. Unit Test doesn’t focus on interaction with external systems and software layers/dependencies.Test Doubles (for example Microsoft Fakes framework) comes into the picture to write unit tests which has dependencies on external libraries and systems etc.

   [ ]

Follow OOP Design and Adopt DI

Following Dependency Injection will allow to convert potential Integration Tests into small and quickly testable Unit Tests by taking advantages of Test Doubles (e.g. Microsoft Fakes, Moq, FakeItEasy frameworks etc.)

   [ ]

Should be thorough

Unit Tests are supposed to test all the possible areas of functionality that are subject to failure due to incorrect input/validation checks/boundary checks etc. for given function/method.

   [ ]

Must be Repeatable

Unit Tests must be repeatable for every build and must produce the same results. The development best practice suggests that if you are working on code that is impacting a Unit Test then you must fix the affected Unit Test as well and ensure that it passes.

   [ ]

Have to be Independent

Unit Tests must be independent of another test. In other words, no collateral damage. Hence, a Unit Test must focus only on a small aspect of big functionality. When this Unit Test fails, it should be easy to discover where the issue is in the code. I.e. can be tested in isolation

   [ ]

Keep it Professional

Even though at times Unit Tests may appear to be very simple and small, you must write Unit Tests with coding practices as good as you use for your main development coding. You may want to follow Refactoring, Code Analysis and Code Review practices and so on as for your Test Projects as well.

  [ ]

No Collateral Damage

Make Sure to Run all related Unit Tests after any dev code change big or small; to verify and ensure that no collateral damage occurs or has been introduced.

  [ ]

If you break it, You bought it

If you are working on a feature and to verify no collateral damage, as a best practice run all the Unit Tests. If you observe that some Unit Tests started failing because of your code changes then you own to Fix those broken Unit Tests to make sure that continue to pass.

  [ ]

Track and  maintain the tests

The test code changes should be tracked and maintained as on-going effort. Continue to follow thedesign principles and coding guidelines.

  [ ]

Code Review the Tests

Just like any other Dev code, Unit Tests also needs to be code reviewed by peer. Regardless of size of the test; follow the process.Code review might include reviewing the name of test method, scenarios covered, conditions checked, scope of assertions and code / design smells etc.

  [ ]

Watch YouTube Video here


.NET Client Profile is supported by .NET Versions 3.5 and 4.0. It is designed for client applications like Console Applications, Windows Forms, WPF Applications and so on. As we all know there are many types of applications and hence what is required by one application may not be necessarily required by another type of application. For example, System.Web is only used by ASP.NET / Web apps, this is of no use for Windows Forms app. The Client Profile version of .NET Framework is a lightweight subset of the Framework. This enables quicker deployment and small installation packages.

Let’s see how Microsoft made the .NET Client Profile

Microsoft removed some of the features from the .NET Framework to make the footprints smaller and optimized. Microsoft chose to remove ASP.NET, MSBuild, Advanced WCF features and support for Oracle databases to reduce the framework into a smaller and optimized footprint. Web Applications don’t support the Client Profile version of the framework. Web applications are server-side and so full .NET Framework installation is recommended, unlike client applications. Microsoft has removed the Client Profile from the latest version of .NET Framework 4.5 and hence with .NET 4.5 there is no Client Profile as shown in the image below.

Why .NET 4.5 doesn’t have a Client Profile

Now if you think from a deployment’s point of view, you would want your installer to be as optimized and small as possible, so it takes the minimum required on the client machine and this can be done by the Client Profile flavor of.NET 3.5 and 4.0. .NET 4.5 is already optimized and tuned for quicker deployment and takes a small amount of disk space for all type of applications. Hence, no more .NET 4.5 Client Profile.


In today’s software development world; we are solving complex business scenarios and developing large business applications. Hence, proper designing is the major factor which contributes to the scalability and performance of any .NET application.

Efficient Resource Management

Resources are very critical for the existence and survival of any application. Examples of resources include objects, files, connections, handles, streams etc. Hence proper handling and cleanup of such resources is critical for the better performance of system.

Here are points to consider:

  • Should properly handle the object creation and cleanup if needed.
  • In .NET some objects offer a Close() method to do proper handling of resources. Some of those are db connection, Streams etc.
  • .NET provides proper structured blocks which can be used in your code to enforce the cleanup if situation arises. For example, finally blocks or using statements can be used to ensure that resources are closed or released properly and in a timely fashion.

Considerations for Crossings the Application Boundary

Applications live and run in their own territory which is defined by the Machine, Process or Application Domains they are hosted in or deployed on. I.e. if two applications communicate with each other across machine, process r app domain there is significant impact on performance of the application.

  • Cross application domain. Since in .NET a process is optimized to have multiple application domains which can then host application inside those app domains. This is the most efficient boundary to cross because it is within the context of a single process.
  • Cross process. Crossing a process boundary significantly impacts performance. You should do so only when absolutely necessary. For example, you might determine that an Enterprise Services server application is required for security and fault tolerance reasons.
  • Cross machine. Crossing a machine boundary is the most expensive boundary to cross, due to network latency and marshaling overhead. Before introducing a remote server into your design, you need to consider the relative tradeoffs including performance, security, and administration.

Single Large Assemblies or Multiple Smaller Assemblies

In .NET assembly is the unit of deployment; an application comes to an existence in the form of an assembly only. Any application you have built after compilation produces an assembly only. All the .dlls your project refers to are .NET Assemblies only.

When working on designing and architecting a solution it is critical to consider that different functionalities, classes and interfaces etc. should be part of one single chunky assembly or should be divided across multiple smaller assemblies.

Here are points to consider

  • To help reduce your application’s working set (in simple terms set of memory pages required to host the application in the process) , you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.
  • Reasons to avoid multiple smaller assemblies:
    • Since you have multiple assemblies consider the cost required in loading metadata for multiple smaller assemblies.
    • JIT compile time will be much more as per count of assemblies.
    • Security checks needed for multiple assemblies.

Continue Reading…

Choosing Right Type of WCF Project

September 20th, 2014 | Posted by Vidya Vrat in .NET | C# - (0 Comments)

Before you begin coding, it very important to understand what type of output and behavior is expected. These questions can be answered by reviewing your Deployment and Test needs as well. In this article I will talk about guidelines for choosing right type of WCF project templates while creating WCF Service(s).

Any application’s life begins with choosing a Project Template. Right type of Project Template has big impact on how your application will shape up, output type etc.

WCF Services Projects are no different than other applications except being biggest player in SOA world.

Different Templates for WCF
Most commonly used type in industry is either WCF Service Library or WCF Service Application, as shown in the image below.









The difference between two depends on your Test and Deployment needs.

Continue Reading Full Article…

Creating & Consuming a DLL in C#

September 10th, 2014 | Posted by Vidya Vrat in .NET | C# | Video Tutorial - (0 Comments)

Microsoft released the CTP2 of Visual Studio 2014 today July 8th 2014.

In my previous News item I mentioned that biggest challenge in trying Visual Studio 2014 was Side-by-Side installation. This issue is claimed to be resolved in this new CTP2 release which can be downloaded from here , whereas I would suggest that you try it with your own responsibility and things might break.

What is CTP anyways?

CTPs are previews for the next major release of Visual Studio. These Visual Studio CTPs are intended to promote continuous feedback between early adopters and the Visual Studio development team.

CTPs have Limitations

CTPs are provided for testing and feedback purposes only. CTPs are unsupportedEnglish-only releases. They are not subject to final validation and are not intended for use on production computers, or to create production code.

Some New COOL Features Added in CTP2

  • Save and Apply Custom IDE Layouts. You can now save and apply custom layouts for tool windows in the IDE. The Save Window Layout and Apply Window Layout commands are under the Window Menu and you can also rename, reorder, and delete layouts from Manage Window Layouts.
  • Light Bulb Editor Adornment. How many times have you found yourself stuck in a complex syntax issue or compilation error which doesn’t seem to go away? I have always wished that there was a legitimate way to have some options displayed as solution to the problem. Microsoft Introduced, Light Bulbs which is an extensible editor adornment to identify and help you fix issues in your code. To use them, place the caret on a line with an issue or hover over an issue and you’ll see a light bulb that lists actions you can take to resolve the problem and even a preview of proposed solutions.
  • Editor Touch Support. All the devices these days are supporting touch. Many software receive direct benefit from the support for touch. Visual Studio Code Editor seem to be an exception to be fully benefited with touch, as development required typing. But a Touch support will certainly enables the developers to do some usual things like scrolling, pinch-to-zoom, tap-and-hold for context menus, double-tap for word selection, and line selection by tapping in the margin etc. All such gestures now acknowledged by Visual Studio 2014 code editor. Needless to mention you have to have a Laptop with Touch Support.
  • ALL CAPS. Remember menu names in Capital letters (All CAPS) was kind of hard to read. SO Microsoft has reverted it to be Title Case (Tools, File, View) as it has been used by various Visual Studio releases.  Microsoft Says.. Last week with the RC for Visual Studio 2013 Update 3 we added an option to sentence case menus; in this VS “14” CTP we changed Menu Bar styling to Title Case for everyone to help us get feedback on the change. 

 So Are you Installing?

I wanted to verify few things and so I chose to install and try the CTP2 bits of Visual Studio 2014. My current laptop settings are as follows:

  • Windows 7 Enterprise
  • Visual Studio 2012 Ultimate
  • Visual Studio 2013 Ultimate
  • newly installed Visual Studio 2014 Professional












Continue Reading….. 



In this article I will share some real-world problems that appear to be complex, but with usage of Microsoft.VisualBasic.Devices those can be easily done.


You are working on an application and you come across any of the following requirements before any action can possibly take place:

  • Verify OS name.
  • Make sure CAPS is ON or NOT (as per your application’s need)
  • Check Network availability before you open a browser or load the site.
  • Does the mouse have a wheel?
  • Ability to Ping a URI or Computer’s IP before your entire business logic starts executing.


All of the preceding specified situations are valid and used in many real-world applications, the issue is that none of them appear straightforward to implement, as it involves:

  • Communication with Operating System; to know the OS name
  • Communication with Hardware; to know if CAPS is ON or OFF
  • Communication with Network Adaptor; to check if Computer is connected to Network on not
  • Communication with Hardware pointing device; Mouse has wheel or not
  • Perform some action over the network; Pinging a computer or URL


Microsoft.VisualBasic.Devices is a namespace that helps in such scenarios. The following code example shows the use of various classes.

In order to use Microsoft.VisualBasic.Devices namespace you must add a reference of it to your project/application.

Continue Reading…


A .NET Client Profile is supported by .NET Versions 3.5 and 4.0. It is designed for client applications like Windows Forms. The Client Profile version of .NET Framework is a lightweight subset of the framework. This enables quicker deployment and small installation packages.

Read My Full Article Here..