VB & ASP.Net Development Code Review Checklist Page 6 of 7
Copyright © 2006 by the Commonwealth of Pennsylvania. All Rights Reserved.
VB & ASP.Net Development Code Review Checklist Page 6 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
Document History
Version / Date / Author / Status / Notes1.0 / 2/6/2008 / Frank Froment / Final / Adapted from PA-NEDSS
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. Development Considerations
5.1. Copyright Notice
Check / Description / Notes // First line of the source module contains a Copyright notice that reflects the current calendar year.
5.2. Input Validations
Check / Description / Notes // Input is constrained and validated for type, length, format, and range.
/ Requiredness checks are performed on data.
5.3. Form or Page Layout (if Applicable)
Check / Description / Notes // 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 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
/ 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