1

Project development Checklist

This section describes the checklist of project development

Project name

Project manager

Team leader

Team member

Quality analyst

Project start date

Confidential – Document
v.092010
 2

Contents

Confidential – Document
v.092010
 3

1 . COMMON

2 . ADO.NET

3 . WEB SERVICE

4 . ASP.NET

Confidential – Document
v.092010
 4

Common Checklist Top Y/N/NA

Have you called dispose or close for memory

management?
• (database-related classes: connection, datareader,
and transaction.

• File-based classes: filestream and binarywriter.

• Stream-based classes: streamreader, textreader,

textwriter, binaryreader, and textwriter.

• Network-based classes: socket, udpclient, and

tcpclient.)

GC.Collect has not been used?

(The garbage collector is self-tuning. By programmatically
forcing a collection with this method, the chances are you
hinder rather than improve performance.)
Do you not repetitively access properties?
(Repeated accessing of object properties can be expensive.
Properties can appear to be simple, but might in fact involve
expensive processing operations. for ( int item = 0; item <
Customer.Orders.Count ; item++ ){
CalculateTax ( Customer.State, Customer.Zip,
Customer.Orders[item] );
}
)
Recursion has not been used?
(if your code uses recursion, consider using a loop instead.
A loop is preferable in some scenarios because each
recursive call builds a new stack frame for the call. This
results in consumption of memory, which can be expensive
depending upon the number of recursions. A loop does not
require any stack frame creation unless there is a method
call inside the loop.
If you do use recursion, check that your code establishes a
maximum number of times it can recurse, and ensure there
is always a way out of the recursion and that there is no
danger of running out of stack space.)

foreach loop has not been used?

(consider using a for loop instead of foreach to increase
performance for iterating through .net framework collections
that can be indexed with an integer.)

Confidential – Document
v.092010
 5

Expensive operations have not been performed

within your loops?

Have you not concatenated strings?

Have you used StringBuilder over string for

concatenation inside the loop?
Have you checked empty string as per the
below example?
(don’t use if ((txtbvtype.text == "")), please use if
(string.isnullorempty(txtbvtype.text)))
Have you used switch case for multiple
conditions?
(use switch case instead of multiple else if conditions)
Have you performed string comparisons with
string.compare for ignoring the case?
Boolean conditions have not been evaluated
against true or false.?
(avoid evaluating boolean conditions against true or false.
If (isvalid){…})
Have you used compound conditional
expressions as per the example ?
(avoid compound conditional expressions – use boolean
variables to split parts into multiple manageable expressions.
// bad!
If (((value > _highscore) && (value != _highscore)) && (value
< _maxscore))
{…}
// good!
Ishighscore = (value >= _highscore);
Istiedhigh = (value == _highscore);
Isvalid = (value < _maxvalue);
If ((ishighscore && ! Istiedhigh) && isvalid)
{…})
Have you used break in loop?
(use break; in loop if condition satisfied)

Have you used finally blocks to ensure

resources are freed?
( make sure that resources are closed after use by using
try/catch blocks. The finally block is always executed, even if
an exception occurs)

Confidential – Document
v.092010
 6

Exception handling has not been used inside

loops?
(check if your code uses exceptions inside loops. This
should be avoided. If you need to catch an exception, place
the try/catch block outside the loop for better performance)
Exceptions have not been rethrown?
(rethrowing exceptions is inefficient. Not only do you pay the
cost for the original exception, but you also pay the cost for
the exception that you rethrow)
Have you initialized the collection to an
approximate final size?
(it is more efficient to initialize collections to a final
approximate size even if the collection is capable of growing
dynamically ex - arraylist objarraylist = new arraylist (43);)
have you not used contains to search arraylists?
(store presorted data and use arraylist.binarysearch for
efficient searches. Sorting and linear searches using
contains are inefficient. This is of particular significance for
large lists. If you only have a few items in the list, the
overhead is insignificant. If you need several lookups, then
consider hashtable instead of arraylist. )
Hashtable has not been used for small amout of
data ?
(if you store small amounts of data (10 or fewer items), this
is likely to be slower than using a listdictionary. If you do not
know the number of items to be stored, use a
hybriddictionary)
Strings have not been stored in hashtable?
(prefer stringdictionary instead of hashtable for storing
strings, because this preserves the string type and avoids
the cost of up-casting and down-casting during storing and
retrieval. )
Late binding has not been used?
(as a result, early-bound objects have better performance
than late-bound objects )
System.object has not been used to access
custom objects?
(avoid using system.object to access custom objects
because this incurs the performance overhead of reflection.
Use this approach only in situations where you cannot
determine the type of an object at design time)
Have you defined only the required variables as
public?

Confidential – Document
v.092010
 7

Have you sealed your classes or methods?

(if you do not want anybody to extend your base classes,
you should mark them with the sealed keyword. Also, if you
derive from a base class that has virtual members and you
do not want anybody to extend the functionality of your
derived class, consider sealing the virtual members in the
derived class. Sealing the virtual methods makes them
candidates for inlining and other compiler optimizations.)
Have you used StringBuilder for append the
traces and write it in the finally block?
Have you not done unnessary typecasting ?
(ex- 1. Convert.ToInt32(e.CommandArgument.ToString())
2. TextBox1.Text.ToString()
)

Confidential – Document
v.092010
 8

Confidential – Document
v.092010
 9

ADO Checklist Top Y/N/NA

Have you closed your connections properly?

(open and close the connection within the method.
Explicitly close connections using a finally or using block.)
Have you pooled your database connections?

Have you executed queries that do not return

data using ExecuteNonQuery?
(if you do not return values from your stored procedure, use
executenonquery for optimum performance.)
Have you executed queries that only return a
single value using ExecuteScaler?
(identify queries that return only a single value. Consider
changing the query to use return values and use
command.executenonquery, or if you do not have control
over the query, use command.executescaler, which returns
the value of the first column of the first row.)
Have you used CommandBehavior.
SequentialAccess if you are accessing very
wide rows or rows with blobs?
(if you are accessing very wide rows or rows with blob data,
use commandbehavior.sequentialaccess in conjunction with
getbytes to access blob in chunks. )
Have you used NoCount if you have multiple
statements within the stored procedure?
(use set nocount on when you have multiple statements
within your stored procedures.)

Confidential – Document
v.092010
 10

Have you explicitly specified the parameter

types?
(specifying the parameter types prevents unnecessary type
conversions that are otherwise performed by the data
provider. Use the enumeration type that is relevant for the
connection used by you; for example, sqldbtype or
oledbtype. )

Have you closed your datareaders and also used

commandbahavior.closeconnection ?
(scan your code to ensure you are closing your datareaders
as soon as you are finished with them. You should call close
or dispose in a finally block. If you pass a datereader back
from a method, use commandbahavior.closeconnection to
ensure the connection gets closed when the reader is
closed. )
Datasets have not been used as return in
webservice?
(inefficient serializing of datasets is a major performance
issue for remote calls. You should avoid sending datasets
(especially when using .net remoting) and consider
alternative means of sending data over the wire, such as
arrays or simple collections, where possible. )
Large dataset object has not been serialized?
(the dataset object generates a large amount of serialization
data and is expensive to serialize and deserialize. If your
code serializes dataset objects, make sure to conduct
performance testing to analyze whether it is creating a
bottleneck in your application. If it is, consider alternatives
such as using custom classes.)
Datatable.Select has not been used?
(if you need to search a dataset using a primary key, create
the primary key on the datatable. This creates an index that
the rows.find method can use to quickly find the required
records. Avoid using datatable.select, which does not use
indices. )
Have you searched data which does not have a
primary key using DataView?
(if you need to repetitively search by nonprimary key data,
create a dataview with a sort order. This creates an index
that can be used to improve search efficiency. This is best
suited to repetitive searches as there is some cost to
creating the index.)

Confidential – Document
v.092010
 11

Have you used IgnoreSchema with datasets for

xml data?
(if you do not pass the schema for the xml data, the dataset
tries to infer the schema at run time. Pass
xmlreadmode.ignoreschema to the readxml method to
ensure that schema is not inferred.)
Long-running transactions have not been used?
(having a long-running transaction with high isolation levels
prevents other users from reading the data. Instead of
locking resources for the duration of the transaction,
consider accommodating various states within your schema
(for example, ticket status pending, instead of locking the
row). Another option is to use compensating transactions)
Have you turned off automatic transaction
enlistment if it's not needed?
(if you use the.net framework data provider for sql server,
you can turn off automatic transaction enlistment by setting
enlist to false in the connection string, as shown in the
following code, when you are not dealing with an existing
distribution transaction. Sqlconnection objsqlconnection =
new sqlconnection( "server=data;integrated
security=true;enlist=false;"); )
Have you used readtext or updatetext to read or
write blobs to sql server database?
(ensure that you use readtext and updatetext to read and
write large blobs to a sql server database. Use readtext to
read text, ntext, varchar, varbinary, or image values. This
enables you to read the data in chunks to improve
performance. Use updatetext to write data in chunks.)
Have you used system.data.oracleclient.
oraclelob to read or write blobs to an oracle
database?
(ensure that you use the system.data.oracleclient.oraclelob
class to read and write blobs to an oracle database. The
read and write methods provide the flexibility of reading and
writing the data in chunks.)
Have you validated the input with a schema
before processing it?
(if you do use validation, make sure you optimize schema
validation performance, for example, by compiling and
caching the schema. You can validate incoming messages
in a separate http module, soap extension or within the web
method itself)

Confidential – Document
v.092010
 12

Confidential – Document
v.092010
 13

Web Service Checklist Top Y/N/NA

Have you used asynchronous web method while

you are performing i/o operations in your web
service?
(if your code performs i/o bound operations such as file
access, consider using an asynchronous web method. An
asynchronous implementation helps in cases where you want
to free up the worker thread instead of waiting for the results
to return from a potentially long-running task.
You should not implement asynchronous web methods when
making a long-running database call because you end up
using delegates that require a worker thread for
asynchronous processing. This degrades performance rather
than increasing it.)

Have you used oneway attribute on the web

method if the client does not expect data back
from the web service?
(if your client does not expect data from the web service,
check if your code uses the oneway attribute on the web
method so that the client does not wait on any results.)

Have you considered calling web services

asynchronously?
(you can improve performance on the client by invoking web
services asynchronously. The proxy generated by visual
studio .net automatically provides two extra methods for
asynchronous invocation of the web service. For example, if
you have a method named myprocess, visual studio .net
automatically generates two additional methods named
beginmyprocess and endmyprocess.
For windows forms applications, you should use
asynchronous invocation to keep the user interface (ui)
responsive to user actions. For server applications, you
should invoke web services asynchronously when you can
free up the worker thread to do some useful work.)
Have you made long-running calls to web
services asynchronously?
(if your web service calls are long-running, you can free up
the worker thread for useful work by invoking the web
services asynchronously.

Confidential – Document
v.092010
 14

Have you used xmlignore to reduce the amount

of data sent over the wire?
(use the xmlignore attribute to avoid sending unnecessary
data over the wire. By default, xml serialization serializes all
the public properties and fields of a class. If your class
includes derived data or codes that you do not want to return
to the client, you can mark members with the xmlignore
attribute.)
Have you set client timeouts greater than your
web service timeout?
(ensure that the client timeouts calling the web service are
greater than the web service timeout. Set the
executiontimeout attribute for the httpruntime element to a
higher value than the proxy timeout for the web service.)

Confidential – Document
v.092010
 15

Confidential – Document
v.092010
 16

ASP.Net Checklist Top Y/N/NA

Have you abort connections when asp.net pages

timeout?
(if you have an asp.net page that calls a web service, it is
possible for the page request to time out before the page
receives a response back from the web service. In this event,
the connection to the web service does not get aborted and
the web service request continues to execute, eventually
returning despite the client page timing out.
To address this issue, tune your time-outs and modify the
automatically generated proxy code to abort the request if
the asp.net page times out.)
Have you used too many variations for output
caching?
(check your pages that use the output cache to ensure that
the number of variations has a limit. Too many variations of
an output cached page can cause an increase in memory
usage. You can identify pages that use the output cache by
searching for the string "outputcache.")
Have you checked for nulls before accessing
cache items?
(you can improve performance by checking for null before
accessing the cached item.)

Have you disabled session state when not

required?
(session state is on by default. If your application does not
use session state, disable it in web.config)
Have you checked for nulls before accessing
items in session state?

Confidential – Document
v.092010
 17

Confidential – Document
v.092010
 18

Complex objects have not been stored in

session state?
(avoid storing complex objects in session state, particularly if
you use an out-of-process session state store. When using
out-of-process session state, objects have to be serialized
and deserialized for each request, which decreases
performance.)

Have you used the application state dictionary?

(you should use application state dictionary for storing read-
only values that can be set at application initialization time
and do not change afterward. There are several issues to be
aware of when using application state in your code, such as
the following:
o Memory allocated to the storage of
application variables is not released unless
they are removed or replaced.
o Application state is not shared across a web
farm or a web garden — variables stored in
application state are global to the particular
process in which the application is running.
Each application process can have different
values.)
Have you not create threads on a per-request
basis?
(avoid manually creating threads in asp.net applications.
Creating threads is an expensive operation that requires
initialization of both managed and unmanaged resources. If
you do need additional threads to perform work, use the clr
thread pool. To find places in your code where you are
creating threads, search for the string "threadstart." )
Have you explicitly closed resources properly?
(ensure that your code explicitly closes objects that
implement idisposable by calling the object's dispose or
close method. Failure to close resources properly and
speedily can lead to increased memory consumption and
poor performance. Failing to close database connections is
a common problem. Use a finally block (or a using block in
c#) to release these resources and to ensure that the
resource is closed even if an exception occurs.)
Have you pooled shared resources?
(check that you use pooling to increase performance when
accessing shared resources. Ensure that shared resources,
such as database connections and serviced components,
that can be pooled are being pooled. Without pooling, your
code incurs the overhead of initialization each time the
shared resource is used.)

Confidential – Document
v.092010
 19

Have you obtained your resources late and

release them early?
(open shared resources just before you need them and
release them as soon as you are finished. Holding onto
resources for longer than you need them increases memory
pressure and increases contention for these resources if
they are shared.)

Have you transfered data in chunks over i/o

calls?
(if you do need to transfer data over i/o calls in chunks,
allocate and pin buffers for sending and receiving the
chunks. If you need to make concurrent i/o calls, you should
create a pool of pinned buffers that is recycled among
various clients rather than creating a buffer on a per-request
basis. This helps you avoid heap fragmentation and reduce
buffer creation time.)
Have you used response.write for formatting
output?
(identify areas in your code where you concatenate output,
such as to create a table, and consider using response.write
instead. Response.write is the most efficient method for
writing content to the client.)
Have you implemented an error handler in
global.asax?
(although implementing an error handler in global.asax does
not necessarily increase performance, it helps you to identify
unexpected exceptions that occur in your application. After
you identify the exceptions that occur, take appropriate
action to avoid these exceptions.)

Have your code avoided exceptions?

(your code should attempt to avoid exceptions to improve
performance because exceptions incur a significant
overhead. Use the following approaches:
o Check for null values.
o Do not use exceptions to control regular
application logic.
o Do not catch exceptions you cannot handle
and obscure useful diagnostic information.
o Use the overloaded server.transfer method
server.transfer(string,bool) instead of
server.transfer, response.redirect, and
response.end to avoid exceptions.)

Confidential – Document
v.092010
 20

Have you taken steps to reduce your page size?

(try to keep the page size to a minimum. Large page sizes
place increased load on the cpu because of increased
processing and a significant increase in network bandwidth
utilization, which may lead to network congestion. Both of
these factors lead to increased response times for clients.
Consider the following guidelines to help reduce page size:
o Use script includes (script tags rather than
interspersing code with html).
o Remove redundant white space characters
from your html.
o Disable view state for server controls where
it is not needed.
o Avoid long control names.
o Minimize the use of graphics, and use
compressed images.
o Consider using cascading style sheets to
avoid sending the same formatting
directives to the client repeatedly.)
Has buffering enabled?
(ensure that you have buffering enabled. Buffering causes
the server to buffer the output and send it only after it has
finished the processing of the page. If buffering is disabled,
the worker process needs to continuously stream responses
from all concurrent requests; this can be a significant
overhead on memory and the processor, especially when
you use the asp.net process model.
To find out if you have buffering disabled, you can search
your code base for the following strings: "buffer" and
"bufferoutput."
Make sure that the buffer attribute is set to true on the
<pages> element in your application's web.config file.
<pages buffer="true">)

Confidential – Document
v.092010
 21

Have you used response.redirect if it is not

needed over Server.Transfer?
(search your code for "response.redirect" and consider
replacing it with server.transfer. This does not incur the cost
of a new request because it avoids any client-side
redirection.
You cannot always simply replace response.redirect calls
with server.transfer calls because server.transfer uses a
new handler during the handler phase of execution.
Response.redirect generates a second request. If you need
different authentication and authorization, caching, or other
run-time devices on the target, the two mechanisms are not
equivalent. Response.redirect causes an extra request to be
sent to the server. Response.redirect also makes the url
visible to the user. This may be required in some scenarios
where you require the user to bookmark the new location.)

Have you reduce redundant processing in

page.IsPostback?
(check that the logic in your page uses the page.ispostback
property to reduce redundant processing and avoid
unnecessary initialization costs. Use the page.ispostback
property to conditionally execute code, depending on
whether the page is generated in response to a server
control event or whether it is loaded for the first time.)
Have you validated user input?
(check that you validate user input on the client to reduce
round trips to the server. This also provides better feedback
to the user. For security reasons, ensure that any client-side
validation is complimented with the equivalent server-side
validation.)

Confidential – Document
v.092010
 22

Have you disabled debugging?

(check your web.config file and ensure debug is set to false
in the <compilation> section and check your .aspx pages to
ensure debug is set to false. If debugging is enabled, the
compiler does not generate optimized code and pages are
not batch compiled. You can check your .aspx pages by
using the findstr.exe file with regular expressions.
C:\pag>findstr /i /r /c:"<%.*@.*page.*debug=.*true*.*%>"
*.aspx
Login.aspx:<%@ page language="vb" debug="true" %>)

Have you disabled tracing?

(check your web.config file to ensure trace is disabled in the
<trace> section. Also check your .aspx pages to ensure
trace is set to false.
You can check your .aspx pages by using the findstr.exe file
with regular expressions.
C:\pag>findstr /i /r /c:"<%.*@.*page.*trace=.*true*.*%>"
*.aspx
Login.aspx:<%@ page language="vb" trace="true" %>)
Have you set aggressive timeouts?
(set timeouts aggressively and tune accordingly. Evaluate
each page and determine a reasonable timeout. The default
page timeout is 90 seconds specified by the
executiontimeout attribute in machine.config. Server
resources are held up until the request is processed
completely or the execution times out, whichever is earlier.
In most scenarios, users do not wait for such a long period
for the requests to complete. They either abandon the
request totally or send a new request which further
increases the load on the server.)
Have you disabled view state when it is not
required?
(evaluate each page to determine if you need view state
enabled. View state adds overhead to each request. The
overhead includes increased page sizes sent to the client as
well as a serialization and deserialization cost. You do not
need view state under the following conditions:
o The page does not post back to itself; the
page is only used for output and does not
rely on response processing.
o Your page's server controls do not handle
events and you have no dynamic or data-
bound property values (or they are set in
code on every request).
o If you are ignoring old data and repopulating
the server control every time the page is
refreshed.)
Confidential – Document
v.092010
 23

Confidential – Document
v.092010
 24

Have you used server controls if needed?

(evaluate your use of server controls to determine if you can
replace them with lightweight html controls or possibly static
text. You might be able to replace a server control under the
following conditions:
o The data being displayed in the control is
static, for example, a label.
o You do not need programmatic access to
the control on the server side.
o The control is displaying read-only data.
o The control is not needed during post back
processing.)
Large result has not displayed on the page?
(identify areas of your application where large result sets are
displayed and consider paging the results. Displaying large
result sets to users can have a significant impact on
performance.)

Have you not used datasets when you could be

using datareaders?
(if you do not need to cache data, exchange data between
layers or data bind to a control and only need forward-only,
read-only access to data, then use datareader instead.)
Page.databind has not been used?
(avoid calling page.databind and bind each control
individually to optimize your data binding. Calling
page.databind recursively calls databind on each control on
the page.)

Confidential – Document
v.092010
 25

Databinder.eval has not been used?

(databinder.eval uses reflection, which affects performance.
In most cases databinder.eval is called many times from
within a page, so implementing alternative methods provides
a good opportunity to improve performance.
Avoid the following approach.
<itemtemplate>
<tr>
<td><%# databinder.eval(container.dataitem,"field1")
%></td>
<td><%# databinder.eval(container.dataitem,"field2")
%></td>
</tr>
</itemtemplate>
Use explicit casting. It offers better performance by avoiding
the cost of reflection. Cast the container.dataitem as a
datarowview if the data source is a dataset.
<itemtemplate>
<tr>
<td><%# ((datarowview)container.dataitem)["field1"]
%></td>
<td><%# ((datarowview)container.dataitem)["field2"]
%></td>
</tr>
</itemtemplate>
Cast the container.dataitem as a string if the data source is
an array or an arraylist.
<itemtemplate>
<tr>
<td><%# ((string)container.dataitem)["field1"] %></td>
<td><%# ((string)container.dataitem)["field2"] %></td>
</tr>
</itemtemplate>)
server.create object has not been used?
(avoid using server.createobject and early bind to your
components at compile time wherever possible.
Server.createobject uses late binding and is primarily
provided for backwards compatibility.
Search your code base to see if you use this routine and as
an alternative, create an interop assembly to take advantage
of early binding.)
Have you tuned thread pool appropriately in
machine.config ?
(proper tuning of the clr thread pool tuned improves
performance significantly. Before deploying your application,
ensure that the thread pool has been tuned for your
application.)

Confidential – Document
v.092010
 26

Have you configured memory limit

appropriately in machine.config ?
(configuring the asp.net memory limit ensures optimal
asp.net cache performance and server stability. In iis 5.0 or
when you use the asp.net process model under iis 6.0,
configure the memory limit in machine.config. With iis 6.0,
you configure the memory limit by using the iis mmc snap-
in.)

Have you removed unnecessary httpmodules?

(including httpmodules that you do not need adds extra
overhead to asp.net request processing. Check that you
have removed or commented out unused httpmodules in
machine.config.)

Confidential – Document
v.092010