C# code review checklist

C# code review checklist

1. Are exceptions used to indicate error rather than returning status or error codes?
2. Are all classes and public methods commented with .NET style comments? Note that <summary>
comments should discuss the "what" of public methods. Discussion of "how" should be in
<remarks> blocks or in-line with the code in question.
3. Are method arguments validated and rejected with an exception if they are invalid?
4. Do classes that should not be instantiated have a private constructor?
5. Are classes declared as value types only infrequently used as method parameters, returned from
methods or stored in Collections?
6. Are classes, methods and events that are specific to an assembly marked as internal?
7. Are singletons that may be accessed by multiple threads instantiated correctly?
8. Are methods that must be overriden by derived classes marked as abstract?
9. Are classes that should not be overriden marked as sealed?
10. Is "as" used for possibly incorrect downcasts?
11. Do classes override ToString instead of defining a Dump method for outputting the object's state?
12. Are log messages sent to the logging component instead of Console?
13. Are finally blocks used for code that must execute following a try?
14. Is foreach used in preference to the for(int i...) construct?
15. Are properties used instead of implementing getter and setter methods?
16. Are readonly variables used in preference to properties without setters?
17. Is the override keyword used on all methods that are overriden by derived classes?
18. Are interface classes used in preference to abstract classes?
19. Is code written against an interface rather than an implementing class?
20. Do all objects that represent "real-world" or expensive resources implement the IDisposable
pattern?
21. Are all objects that implement IDisposable instantiated in a using block?
22. Do all exception classes derive from the base Matrix exceptions and fit correctly into the exception
hierarchy?
23. When doing floating point calculations, are all constants doubles rather than integers?
24. Do all delegates have a void return type and avoid using output or ref parameters?
25. Do all delegates send the sender (publisher) as the first argument? This allows the subscriber to
tell which publisher fired the event.
26. Are delegates published as events? This prevents the subscribers from firing the event.
27. Are all the conditional paths reachable?
28. Are all the individual conditions in a complex conditions separately evaluated?
29. If there is a nested IF statement, are the THEN and ELSE parts appropriately delimited?
30. In the case of a multi-way branch like SWITCH/CASE statement, is a default clause provided? Are
the breaks after each CASE appropriates?
31. Is there any part of code that is unreachable?
32. Are there any loops that will never execute?
33. Are there any loops where the final condition will never be met and hence cause the program to go
into an infinite loop?
34. What is the level of nesting of the conditional statements? Can the code be simplified to reduce
complexity?
35. Are bounds to array subscription and pointers properly checked?
36. Is StringBuilder used for complex string manipulations and to concatenate strings multiple times?

Do You Use Strongly Typed Arrays?

Identify places in your code where you use object arrays (arrays containing the Object type). If you use
object arrays to store other types, such as integers or floats, the values are boxed when you add them to
the array. Use a strongly typed array instead, to avoid the boxing. For example, use the following to
store integers.

int[] arrIn = new int[10];

Use the preceding to store integers instead of the following.

Page 1 of 4
 C# code review checklist
Object[] arrObj = new Object[10];

Do You Use Session State?

Use the following review questions to review your code's use of session state:

• Do you disable session state when not required?

Session state is on by default. If your application does not use session state, disable it in
Web.config as follows.

<sessionState mode="Off" />

If parts of your application need session state, identify pages that do not use it and disable it for
those pages by using the following page level attribute.

<@% EnableSessionState = "false" %>

Minimizing the use of session state increases the performance of your application.

• Do you have pages that do not write to a session?

Page requests using session state internally use a ReaderWriterLock to manage access to the
session state. For pages that only read session data, consider setting EnableSessionState to
ReadOnly.

<%@ Page EnableSessionState="ReadOnly" . . .%>

This is particularly useful when you use HTML frames. The default setting (due to
ReaderWriterLock) serializes the page execution. By setting it to ReadOnly, you prevent
blocking and allow more parallelism.

• Do you check for nulls before accessing items in session state?

You can improve performance by checking for null before accessing the item, as shown in the
following code.

object item = Session["myitem"];

if(item==null)
{
// do something else
}

SQL Injection
Your code is vulnerable to SQL injection attacks wherever it uses input parameters to construct SQL
statements. As with XSS bugs, SQL injection attacks are caused by placing too much trust in user input
and not validating that the input is correct and well-formed.

The following process helps you locate SQL injection vulnerabilities:

1. Look for code that accesses the database.

Scan for the strings "SqlCommand," "OleDbCommand," or "OdbcCommand."

Page 2 of 4
 C# code review checklist
2. Check whether the code uses parameterized stored procedures.

Stored procedures alone cannot prevent SQL injection attacks. Check that your code uses
parameterized stored procedures. Check that your code uses typed parameter objects such as
SqlParameter, OleDbParameter, or OdbcParameter. The following example shows the use of
a SqlParameter:

SqlDataAdapter myCommand = new SqlDataAdapter("spLogin", conn);

myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@userName", SqlDbType.VarChar,12);
parm.Value=txtUid.Text;

The typed SQL parameter checks the type and length of the input and ensures that the userName
input value is treated as a literal value and not as executable code in the database.

3. Check that your code uses parameters in SQL statements.

If you do not use stored procedures, check that your code uses parameters in the SQL statements
it constructs, as shown in the following example:

select status from Users where UserName=@userName

Check that the following approach is not used, where the input is used directly to construct the
executable SQL statement using string concatenation:

string sql = "select status from Users where UserName='"

+ txtUserName.Text + "'";

4. Check whether or not your code attempts to filter input.

A common approach is to develop filter routines to add escape characters to characters that have
special meaning to SQL. This is an unsafe approach, and you should not rely on it because of
character representation issues.

Cross Site Scripting:-

refer http://msdn.microsoft.com/en-us/library/Aa302437#c21618429_005

Check the validateRequest Attribute

Web applications that are built using the .NET Framework version 1.1 or later perform input filtering to
eliminate potentially malicious input, such as embedded script. Do not rely on this, but use it for defense
in depth. Check the <pages> element in your configuration file to confirm that the validateRequest
attribute is set to true. This can also be set as a page-level attribute. Scan your .aspx source files for
validateRequest, and check that it is not set to false for any page.

Check the HttpOnly Cookie Option

Internet Explorer 6 SP 1 supports a new HttpOnly cookie attribute that prevents client-side script from
accessing the cookie from the document.cookie property. Instead, an empty string is returned. The
cookie is still sent to the server whenever the user browses to a Web site in the current domain. For
more information, see the "Cross-Site Scripting" section in Chapter 10, "Building Secure ASP.NET Pages
and Controls."

Page 3 of 4
 C# code review checklist
Check the <frame> Security Attribute

Internet Explorer 6 and later supports a new security attribute on the <frame> and <iframe>
elements. You can use the security attribute to apply the user's Restricted Sites Internet Explorer
security zone settings to an individual frame or iframe. For more information, see the "Cross-Site
Scripting" section in Chapter 10, "Building Secure ASP.NET Pages and Controls."

Check the Use of the innerText and innerHTML Properties

If you create a page with untrusted input, verify that you use the innerText property instead of
innerHTML. The innerText property renders content safe and ensures that script is not executed.

Page 4 of 4