Code review in TFS is an important concern. In this presentation we will learn now to implement best practices while doing code review with TFS.

1. “Think Twice. Code Once.”

2. What is Code Review?
“Code review is the systematic examination (often known as peer review) of
computer source code. It is intended to find and fix mistakes overlooked in
the initial development phase, improving both the overall quality of software
and the developers' skills.”
Going By Wikipedia :
It involves making pieces of source code
available for other developers to review, with
the intention of catching bugs and design
errors before the code becomes part of the
product.

3. Why do we need Code Review?
 Mistakes are caught before they become a part of the product
 Reviewing code by a second-eye points out the mistakes made at the time of
development, and correction at that time itself, reduces the bugs reported by the
testers and also the cost of testing.
 It ensures that codes follow standards defined by the organization's coding guidelines
even if the team is geographically distributed.
 Repetitive code blocks can be caught during a code review process and refactoring can
be done based on that.
 Code reviews can often find and remove common vulnerabilities such as format string
exploits, race conditions, memory leaks and buffer overflows, thereby improving
software security.
 It acts as a knowledge sharing platform by fostering greater communication and
providing invaluable educational context to junior developers.

4. Traditional Code Reviews
The idea of a formal, systematic code review
generally consisted of a bunch of people sitting
together around a table in a stuffy room, poring over
dot-matrix print-outs of computer code together, red
pens in hand, until they were bleary-eyed and brain-
dead.

5. The Code Review Process

6. What to check in a Code?
Flaws or potential
flaws
Consistency with the
overall program design
The quality
of comments.
Adherence to coding
standards.

7. Code Review Checklist
Naming Of Variables :
 Variable Names should follow Camel Casing.
 Variable Names should be meaningful and complete. Abbreviations should be
avoided.
 Do not use underscores (_) for local variable names.
 All Global variables in a class should be prefixed with underscore (_) so that they
can be identified from other local variables.
Bad : xx, xyz, a, cusordhis
Good : customerOrderHistory
Bad : amt, prc
Good : amount, price
Bad : customerorderhistory
Good : customerOrderHistory
Bad : globalCustomerName
Good : _customerName

8. Naming Of Methods :
 Method Names should follow Pascal Casing (Title Case).
 Method Name should be meaningful and complete. Abbreviations should be avoided.
 Method name should denote what it does.
 Async method should have suffix Async.
Bad : getrequiredfields
Good : GetRequiredFields
Bad : getlic, retdt
Good : GetLicense, ReturnDataTable
e.g. GetClientLicenseKey, ExecuteDeleteQuery
Bad : asyGetStock
Good : GetStockAsync

9. Naming Of Classes :
•Class Names should follow the Pascal Casing.
•Class Names should be meaningful and complete. Abbreviations should be avoided.
•Classes should be grouped and created in folders according to function.
•Classes should only expose methods and members which are required to be
accessed from outside the class
Bad : stockitem
Good : StockItem
Bad : Lic, tlydtimport
Good : Licensing, TallyDataImport

10.  Interfaces should start with I.
 Constants should be in all CAPS.
 Namespace, Folders should be in Pascal casing.
Bad : InterfaceStock
Good : IStock
Bad : secretKey
Good : SECRET_KEY
e.g. namespace AppResources

11. Commenting :
 All public / internal methods should have comments providing details of the
purpose of the function. Use XML comments ("///").
 Regions are used for long code blocks.
 Region names are meaningful.
 Any bug fix or code change should have Bug ID, Developer Initials, Date and short
comment.
/// <summary>
/// This class performs an important function.
/// </summary>
public class MyClass{}
#region MyClass definition
public class MyClass
{
static void Main()
{
}
}
#endregion
//ID:231 RK 02.03.2015 Changed the logic to take care of long item names

12. Coding Practices :
 Long functions / code block should be split into smaller functions.
Testing or Debugging of a code that does a lot of things is difficult. Write each
function so that it does one thing and only one thing.
 Hardcoded values should be defined in constant or config.
public static class ConstantVariables
{
public const string ConstantVariable1 = "my string";
}
use:
this.Text = ConstantVariables.ConstantVariable1;
Example using constant values:

13. •Add a reference to System.Configuration
•Add an "Application Configuration File" to your project
•Add a configuration key to the configuration file like:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="myConfiguration" value="TestValue"/>
</appSettings>
</configuration>
•Within the code you can refer to the config file by using:
string configValue = System.Configuration.ConfigurationManager.AppSettings["myConfiguration"];
Example using config file:

14. Error Messages :
 Error messages should be defined in a central class.
 Error message should tell the user of the problem and the way to solve the
error or else it should ask the user to contact support / system administrator.
Incorrect :
• "Error in Application“
• "There is an error"
Correct :
• "Failed to update database. Please make sure the login id and
password are correct."

15.  Try catch is used for exception handling and not for flow control.
 Blank catch block is not used.
 Large try catch blocks should be split into smaller ones.
Error Control :
try {
myLabel.Text = school.SchoolName;
}
catch {
myPanel.Visible = false;
}
Bad Practice :
if (school != null) {
myLabel.Text = school.SchoolName;
}
else {
myPanel.Visible = false;
}
Good Practice :

16. Others :
 Assembly version is set according to version policy in Support Portal.
 Unit tests have been defined for the functions and methods.
 You can also add any specific comments or reviews.
 The event handler should not contain the code to perform the
required action. Rather call another method from the event handler.

17. Problems with Code Review
NO NEED TO DOUBLE
CHECK THIS CHANGE LIST,
IF SOME PROBLEM
REMAINS, THE REVIEWER
WILL CATCH THEM.
NO NEED TO LOOK AT THIS
CHANGE LIST TOO
CLOSELY, I’M SURE THE
AUTHOR KNOWS WHAT HE
IS DOING.