Pennsylvania Department of Health
Bureau of Information Technology
VB & ASP.Net Development
Code Review Checklist
Copyright © 2006 by the Commonwealth of Pennsylvania. All Rights Reserved.
VB & ASP.Net Development Code Review Checklist
Page 2 of 7
Table of Contents
1.
Introduction ....................................................................................................4
2.
VB and ASP.Net Development Peer Review Checklist ......................................4
3.
General Design Considerations (if Applicable) ................................................4
4.
Form and/or Web Design Considerations (if Applicable) .................................4
5.
Development Considerations ...........................................................................4
5.1.
Copyright Notice ........................................................................................... 4
5.2.
Input Validations .......................................................................................... 5
5.3.
Form or Page Layout (if Applicable) ................................................................. 5
5.4.
VB Code Module and Project Settings .............................................................. 5
5.5.
Exception Management .................................................................................. 7
6.
Administration Considerations (if Applicable) .................................................7
Version 1.0 – 6 February 2008
VB & ASP.Net Development Code Review Checklist
Page 3 of 7
Document History
Version
Date
Author
Status
Notes
1.0
2/6/2008
Frank Froment
Final
Adapted from PA-NEDSS
Version 1.0 – 6 February 2008
VB & ASP.Net Development Code Review Checklist
Page 4 of 7
1.
Introduction
2.
VB and ASP.Net Development Peer Review Checklist
Before submitting your code for Peer Review the following checklist must be completed.
Submit this document and the “Code Review Process” form to the reviewer(s).
Author
Project Name (if applicable)
Object Name (if applicable)
Note: If an item(s) is not applicable, type "n/a" in place of the check box.
3.
General Design Considerations (if Applicable)
Check
Description
Notes
The design promotes reuse through sufficient functional decomposition,
abstraction of commonly needed functions into framework components, and
the creation of reusable complex controls where appropriate.
Instrumentation has been considered and used for monitoring critical business
functions
4.
Form and/or Web Design Considerations (if Applicable)
Check
Description
Notes
Navigation follows the page or form flow design document.
Layout is consistent with design documents.
Links are provided to the home page, previous page and related pages.
Navigational tools to allow easy movement from level to level
Information displayed or contained has been checked for quality, accuracy and
legality.
The page is self explanatory in its use or is properly explained.
Graphics and icons download at an acceptable rate when at low speeds.
Page graphics and icons are consistent throughout the form(s) or page(s).
Page(s) or User Control(s) are cached when possible.
5.
5.1.
Check
Development Considerations
Copyright Notice
Description
Notes
First line of the source module contains a Copyright notice that reflects the
current calendar year.
Version 1.0 – 6 February 2008
VB & ASP.Net Development Code Review Checklist
5.2.
Check
Page 5 of 7
Input Validations
Description
Notes
Input is constrained and validated for type, length, format, and range.
Requiredness checks are performed on data.
5.3.
Check
Form or Page Layout (if Applicable)
Notes
Description
If applicable style sheet formats are used. No custom formatting.
Text is easily readable.
Proper use of User Controls to create a standard NEDSS template and
look/feel.
Proper use of “VS 2005 Templates” and ASP.Net 2.0 “Master Page” features
wherever applicable
5.4.
VB Code Module and Project Settings
Check Description
Notes
Does your code look to the future and allow for maintenance or
enhancements?
Option Strict and Option Explicit are both set to On.
Classes are named in Pascal case and are descriptive.
Classes have appropriate suffix for Business Object: BO, Business Entity: BE,
Data Access Object: DAO
No type prefixes are used except for UI elements.
Ex: txtPatientName (text box), PatientName (variable)
Local variables and method parameters are Camel case. No underscores.
Ex: currentPatient
Class variables, methods, objects, events, and enumerations are Pascal case.
No underscores.
Ex: CurrentPatient, ListChanged
Class constants are all UPPER case with underscores between each word.
Ex: MAX_PATIENTS_PER_SCREEN
Abbreviations are clear and consistent. Do not use multiple versions for a
single word, such as Org and Orgn. Use one version and stick to it. Also,
abbreviations should be pronounceable; otherwise it is difficult to refer to.
If an abbreviation cannot be created that is pronounceable, do not abbreviate.
Code comments are used where code contains logic that will not be easily
understood. Code comments should not be used as an alibi for poor
programming.
Import Statements are marked ‘system’ or ‘custom’. If custom what is the
reason?
Web references have the “URL Behavior” property set to “Dynamic” and the
Web.config file is properly noted in the appSettings section
No database connections exist. All database connections are done through a
Version 1.0 – 6 February 2008
VB & ASP.Net Development Code Review Checklist
Page 6 of 7
Check Description
Notes
Data Access Object
Strong data types are used. The use of “Object” variables are not suggested
and must be justified.
Does not type-cast unnecessarily. For example, do not call a method that
returns CustomList(Of SearchBE) and attempt to assign it to variable of type
CustomList(Of BEBase). When the required type is known, use it.
Do not create multiple identifiers with the same name that differ only in scope.
For example, a class variable called PatientName and a local variable in one or
more methods called patientName. Generally, unless processing lists, there
will be very little need for this situation. The method should almost always
refer to the class variable directly without local copies.
Check for overly long sub-routines or methods and break them up into several
smaller and well-defined methods.
Avoid code blocks that are duplicated in multiple places. Put such code in a
method and call the method where the code once resided.
All dead and unreachable code is removed. This includes commented-out code
blocks.
Configuration tables are used. Configuration file use is kept to a minimum and
justified
Standard XML schema is used for class and method header comments and is
current. Comments are updated when method and/or class is modified.
Application secrets are properly implemented utilizing framework components
Trace and debug statements are used where appropriate
Subroutines and functions have been decomposed to a reasonable length
(generally less than 3 pages).
Uses white space to logically group related statements
Uses indentation to show statement nesting and relationships
Only one statement per line
Only one declaration per line
Instantiates objects in their declaration, not in separate statements.
Always use & to concatenate strings, never use the + operator. When
concatenating 4 or more times to build a single String, use StringBuilder
instead.
Declares Boolean variables in the positive case. Example: IsFound, not
IsNotFound
Never uses literals in the source code. Declares constants and refers to them,
or defines the value in a configuration table, configuration file, or resource file.
For example: Stored procedure names, image names, URLs, dates, db table
and field names, text messages, etc.
Scopes variables appropriately
Do not pass class-level variables between Private methods. Local Method
variables may be passed.
Uses line continuation characters to break long lines of code to avoid horizontal
scrolling
Version 1.0 – 6 February 2008
VB & ASP.Net Development Code Review Checklist
Page 7 of 7
Check Description
Notes
AssemblyInfo contains required class attributes
Assemblies are created with the fully qualified name (for example,
PADOH.NEDSS.Web.Session.dll, not Session.dll)
Comments are used for complex logic, and not used where code is clear and
unambiguous
Proper use of Caching.
For example: Use of some utility method in the right layer (Presentation Layer
when appropriate) to access the cached data (ex: code tables).
Appropriate naming conventions are used while naming the files and classes.
For example: suffix the file and class names with BO, BE, DAO, Façade
corresponding to Business Object, Business Entity, Data Access Object or
Façade Object respectively.
All application business logic is accessed through the Business Facade Layer
objects. Explain if not.
Proper use of Controls.
For example: Use of NEDSS controls and not the Infragistics or default ASP.net
controls.
5.5.
Exception Management
Check Description
Notes
Structured exception handling is used where appropriate, not used where
inappropriate. Exceptions are never handled and simply thrown again.
Exceptions are handled, logged, and re-thrown in façade layer; handled in the
UI layer; unhandled elsewhere.
Exception details are logged to the system’s event log via the framework.
Specific catch statements are used where possible.
Errors are raised to the calling module or object where appropriate.
6.
Administration Considerations (if Applicable)
Check Description
Notes
Unnecessary references and imports are removed.
If applicable, tracing is disabled with:
<trace enabled="false" />
If applicable, debug compilations are disabled with:
<compilation debug="false" explicit="true" defaultLanguage="vb">
Technical documents are up to date to include installation, requirements, and
design and development documents.
Version 1.0 – 6 February 2008