.Net Agile code review

Benefits of Performing Code Reviews

The only constant is change. In 2015, we did not have a formal code review process. However in 2016, we decided to change how we build software. Reliable software. Now we have introduced a formal code review process. In a nutshell, we have to pull down the subversion branch or branches and review each revision. The review process also involves compiling code, running unit tests, and trying to break the code. With this in mind, I wanted to share the benefits of performing code reviews.

Reduce Bugs

While performing code reviews for a year, we have concluded that bugs have been reduced significantly. The developer looking at the code changes is wearing a quality analyst hat during this time. If the code review is done correctly, he or she should find bugs. Sometimes it is a simple misspelled word, other times code won’t compile, or a unit tests fails. Many studies have found that finding bugs during development is less expensive than finding the same bug in production. If we encounter a bug six months from now, the developer will have to spend more time understanding the bug and trying to come up with a feasible solution.

Get Familiar with Code

Many times we have to review code that we have never seen. This is a great opportunity to learn about it. Sit down with the developer and ask questions. In our team, we have a developer who is in charge of applications written with PowerBuilder. He asked me to review his code and we sat down together to complete this important step in our development process. Most of our applications are written with .Net but having the knowledge of the PowerBuilder applications allow us to get familiar with all of our applications. Don’t be afraid to learn something new.

Learn New Tips and Tricks

Recently we had the opportunity to use PostgreSQL within a .Net application. Our team spent a lot time looking at syntax because it was our first time using PostgreSQL. One of the things we had to figure out was how to set the primary key. At the beginning we created sequences and it was a 2 step process. However when I had to do a peer review, I did not see a sequence created but a serial. Using serial was much simpler and the team liked the simplicity of using serial vs sequence. We also learn new tips when reviewing code together. Developer and reviewer sitting next to each other discussing code changes. Many times we picked keyboard shortcuts and tricks that improved how we built software.

Keep Code Consistent

If you look at our code base, it looks like the same developer wrote it. It contains the same architecture. It uses the same naming convention. Having a formal peer review process has allowed our team to keep the code consistent. This also helps new developers jump right into our code and be productive. The new developer does not have to learn 3 or 4 different architectures.

There are many benefits in doing code reviews. In our experience, we have seen the number of bugs reduced because bugs were found during development. Our developers were able to fix the bugs while we were in development. We have also be able to keep a consistent code base with the same architecture.


.Net code review General

My top 3 ReSharper keyboard shortcuts


Recently I had a chance to upgrade ReSharper, a visual studio plugin to help .NET developers be more productive. If you are not using ReSharper, you are missing out on lots of features. In this post, I want to share the top 3 ReSharper keyboard shortcuts that help me write better code.

1. Go To Implementation [Control Shift Alt B]
This is one of my favorites ReSharper keyboard shortcuts. In my current project, we use interfaces extensively. Using interfaces help us write unit tests around our classes. When we are debugging, the go to implementation keyboard shortcut is a must have tool. Many times we read stack traces and we know the method name and it is there that we start our debugging process. To use Go To Implementation, right-click on a method and select the Go To Implementation from the pop-up menu. If you are like me and prefer to use keyboard shortcuts, press control shift alt b at the same time. I try to memorize these shortcuts so I can keep my hands on the keyboard.

2. Go To Declaration [Control B]
If you want to go where a method has been declared, right-click on the method or class that you want to inspect and select Go To Declaration. The keyboard shortcut for Go To Declaration is Control + B.

3. Find Usages Alt F7
This key comes very handy when you are about to make changes and want to see all possible changes. If I have to refactor a piece of code and see a lot of usages, most of the time I will not modify that code but instead create a new method or class. To use the Find Usage tool, right-click on your code and select Find Usages or Alt + F7.

I hope you find these shortcuts helpful while writing .Net applications. In a future post, I will write how to use ReSharper to perform code reviews.
code review General

Things I do before a code review

If you have contributed to an open source project, you probably know what a code review is. Github is a great platform to experience code reviews. By default, only project owners have write permissions. For collaborators, the first thing they have to do is fork a project. Once they have their own project with write permissions, they can add new features or fix a bug. When the code is ready for a code review, a pull request is created to start the review process.

In this post, I want to share what I do before submitting my code for a code review.

1 Test my own code

By default, software developers are not good testers. We put our energy and effort on writing code and verifying that requirements get met. But when it comes to code reviews, it is important that your code works as expected. Go thru all the pages you have modified and test them. Try to break your own code. For example, if you have an input that takes only numbers, try to enter strings or add more than 5 decimal places.

2 Clean up

Before I submit my code for a formal review, I pay special attention to comments. Sometimes comments do not reflect what the code is currently doing. If this is the case, I update the comments or remove them entirely.

Another area that I like to clean up is the using statements at the top. If you no longer use a library, it is a good idea to remove it. If you do remove something, make sure to rebuild your projects.

3 Make code more readable

Have you seen code without blank lines in it? I see it all the time. For example, a Javascript function made up of 20 lines but there is no blank lines in it. This makes it very difficult to read it. For the sake of everyone in your team, add blank lines to help code reviewers read the code.

4 Verify unit tests

After you go thru the clean up process, I recompile and run all unit tests. We have a Jenkins server that handles our continuous integration. As part of that build process, all unit tests are run. The last thing you want to do is submit your code for a peer review when unit tests are not passing.


If you are not using code reviews before your code gets into production, you are doing a big mistake. Code reviews allow teams to identify bugs early on. It is more difficult to fix bugs once they make it into production. And they are also more costly. Code reviews also keep your code consistent and clean. Not all companies use code reviews but they are a great tool to keep a clean and stable code base.

code review Javascript python ruby

Improving your code reviews

codestyleCode reviews are an essential practice in any software development team. It allows you to keep your code consistent. It also allows other developers to become familiar with your code changes. Embracing code reviews helps keep your code base healthy.

To improve your code review process, you can do the following:

  1. Document your code style
  2. Allow more than 1 developer to perform the code review
  3. Keep your code changes small

Document your code style

If you don’t document your code style guideline, it is very difficult to keep your code consistent. Some developers might use 2 spaces to indent, others might use 4 spaces to indent. If you have a code style guideline available to all developers, it is easy to enforce it. In addition to be enforced, it is easy for programmers to follow it. You don’t have to open up different files to see the current style guide. You should go to the official style guide for your team or company.

The Python community has documented their code style guide. They created a code style guide under PEP8. One of those conventions is to use 4 spaces per indentation level.

Google has a Javascript style guide. One of the conventions found in the Javascript guide is to always use the keyword var to define variables. Another convention in that document is to always use semicolons.

The Ruby community has also created a style guide. It is hosted at Github and you can see the source here. In contrast to the Python community, they prefer to indent with 2 spaces. See the following example taken from their style guide:

# bad - four spaces
def some_method

# good
def some_method

As you can see from these examples, there are code styles available to help us start with our own documentation. If your team does not have their own style guide, then you can at least document that you will follow Google’s Javascript style guide for example.

Allow more than 1 developer to do the code review

After you have your style guide in place, it is very easy to perform code reviews. It is very important that more than 1 developer in your team can review code changes. Sometimes the team lead might be busy or not available and you don’t want your team waiting on that person. They can go to another developer to do the code review. I believe this is a big problem with a lot of open source projects. Some of these popular projects have few developers in charge of the code reviews and many times the pull requests are not handle in a timely manner.

Keep your code changes small

It is easier to code review 1 or 2 files than to review 20 files. If you have a large number of files, the code review takes a very long time to complete. It is recommended to keep your code changes small. For example, if you have database, business logic, and HTML changes, you can break those changes into 2 or 3 code reviews.


If your team performs code reviews in a daily basis, your code base will stay consistent and hopefully bug-free. Based on my experience as a software developer, having a code style guideline, rotating the person performing the code review, and keeping your code changes small, will allow your code review process to be fun and enjoyable.