Quality Control

Starting from designing to maintenance of a software application package, few standards need to be followed at all stages of the software development. Among all the phases the implementation phase of software development is concerned with translating design specifications into source code. The primary goal of implementation is to write source code and internal documentation so that conformation of the code to its specifications can be easily verified. This goal can be achieved by making the source code as clear and straightforward as possible.

* Simplicity clarity and elegance are the hallmark of good programs.

Source-code clarity is enhanced by structured coding techniques, by good coding style, by appropriate supporting documents, by good internal comments, and exploiting the features provided in modern programming languages.

Production of high quality software requires:

• the programming team has a designated leader
• a well defined organizational structure
• a thorough understanding of the duties and responsibilities of each team member
• implementation team should be provided with a well defined set of software requirements, an architectural design specification and a detailed design description
• each team member must understand the objective of implementation

*Those who write clearly have readers, those write obscurely have commentators

To enhance the source code clarity and that of the end product we have what is known as structured coding techniques and coding standards for a preferred coding style. The quality of the end product can be improved by specifying the various guidelines to be followed while coding, the naming conventions to be used, and the form, report, and screen layout.

* A good workman is known by his tools

Top

1.1 Coding Standards and Its Importance

Coding standards are sometimes ridiculed by developers who think that what they write should be obvious to everyone. But good structure, proper naming and appropriate commenting can provide an outline of the code. The advantages of following good coding standards are as follows:

• manage complexity of the software
• keeps the code organized so as to find mistakes and make corrections
• provides a consistent look to easily read and understand the software
• any developer familiar with the standards will be able to pick any piece of code and able to understand what it does
• helps while doing testing or code walkthrough or code reviews
• there is a smooth transition to the maintenance activities if somebody else is doing it

1.1.1 Commenting for clarity

Adding comments can ease the task of finding bugs and correcting them, better understanding of the code by the programmer for future reference, make modifications as and when required. Comments provide an outline of the code and to describe the purpose of the code. Comments should be added to answer "what" and "why" but not "how": Comments can be added to a program at various stages as follows:

• module comments
• routine comments
• body comments
• variable comments

1.1.2 Structured routines

Giving some structure to routines can improve the readability and clarity of the code. Few of the measures to be taken are as follows:

• indenting for better structure
• declaring variables first
• one routine should be used for one purpose
• one exit point

1.1.3 Variable scope minimization

Scope is used to describe the extent to which a variable can be seen in an application. We can have global or public scope if it can be accessed to all the routines in a project or local or private scope if it is only visible to the module. It is best to use the smallest scope possible for a variable.

1.1.4 Syntax standards

Syntax standards make the application code more consistent and ensure that all the programmers involved in a project follow the same standards. 

* A hidden flaw never remains hidden

Top

1.1.5    Error Handling

A coding standard for error handling should include three steps:

• check for the error
• handle the error
• proceed appropriately

* To err is human, but not able to detect is a blunder

Validation of the input is a must and is an important aspect of any software. All the inputs accepted form the user should be validated properly before storing it into the actual database. If no validation will be carried out then the database will be consistent and may not work properly.

1.2 Coding Style and Its Importance

The highlights of good coding style are:

• use of few standards agreed upon control constructs
• use of goto in a controlled manner (avoid totally if possible)

The highlights of good coding style are: use of few standard agreed upon control constructs

• use of goto in a controlled manner (avoid totally if possible)
• introduction of user defined data types (classes)
• hiding data structures behind access functions (achieved using classes)
• use of proper commenting for each function or subroutine
• carefully examine routines having very few or too many executable statements
• use proper indentation, parentheses, blank spaces, blank lines and borders around comment blocks to enhance readability

The don’ts of good coding style are:

• don’t use an identifier for multiple purposes
• restrict the subroutine size to some predetermined value
• don’t nest too deeply (maximum 3 to 4 levels)
• don’t use complex constructs

1.3 Naming Standards and Its Importance

Naming conventions provide readable, memorable and unambiguous names to help developers read and maintain software applications. It helps the software developer to know what is the type and purpose of the variable used. Few general guidelines on naming are as follows:

• don’t use very short or very long names
• the name of a particular object or variable should specify its purpose
• avoid using the same name for more than one purpose
• consistency should be maintained in naming variables and various objects

4.1 Standards in Naming

Proper naming standards should be followed for objects, routines and variables. Object naming conventions make it easy to recognize which object is used and for what purpose. Constant variable naming conventions differentiate constant variables from the normal variables. Naming can be divided into the categories as shown below.

• object
• module
• variable
• menu
• table and its attributes
• constants
• routines

4.2 Object Naming Conventions

Top

4.3 Module Naming Conventions

Module name depends on the type of the module. The module naming standards to be followed are as follows:

• standard modules should have a prefix of M like MMain
• all class modules should start with cls like clsMarks

4.4 Routine naming conventions

Routine naming conventions to be followed are as follows:

• all standard event procedures should be <object>_<verb> format

Examples: Class_Terminate, txtName_Click, frmMain_Load

• all public routines should be of <verb><object> syntax

Examples: ReadFile, WriteFile

all private routines should follow the <object><verb> syntax

Examples: FileOpen, FileClose

4.5 Menu naming conventions

The menu naming standards to be followed are as follows:

• all menu handler name should be prefixed by "mnu" followed by the menu caption sequence.
• If the menu caption sequence is Help, Contents then the menu handler name should be mnuHelpContents.

• Naming standards for menus will be application specific and the shortcut keys should be taken care of
• menu caption sequence and shortcut keys should be that of Microsoft Word

4.6 Variable Naming Conventions

The variable naming convention to be used is that of Hungarian naming convention frequently used in C and many other high level languages. This notation includes a prefix and a body. The prefix describes the scope and the data type of the variable. The body should specify the purpose of the variable. The prefixes to be used for variables of different type and scope are as follows.

Top

4.6.1 Variable type, scope and the prefixes to be used

4.7 Table and its Attributes Naming Conventions

Table and its attribute naming should follow the standards as shown below:

• name of the table should specify its purpose
• attributes should have a two word prefix specifying the table to which they belong

Example: If the table name is "Student" then an attribute for specifying the roll of the student should be "STRollNum".

Top

18.1 Commenting Standards

The commenting standards to be followed at various stages are as follows:

• Module/Class comments: All modules should start with a brief description of the module and any revisions made to the module in future.

‘Class Name: clsStudent

‘Type: Entity class

‘Description: Student entity class

‘Author: Manoranjan Mishra

‘Date: 22/08/2000

‘Modified by: Rajendra Nanda

‘Date of Modification: 24/08/2000

‘Purpose of Modification: Addition of new routine

• Routine comments: All routine should begin with a brief comment describing the general purpose of the routine, i.e., what it does and the parameters passed to returned from the routine. Stress should be given on "what" and "why" not on "how" the function does.

‘Function: GetElapsedTime‘Description: It returns a number specifying the number of ‘ seconds since the system was started. And has ‘ better resolution. Source: "Visual Basic

‘ Source Code Library--BRIAN SHEA, ET AL.,

‘ Page-16".

‘Prototype: GetElapsedTime() As Single‘Parameters: None‘Return Type: Single‘Limitation: None‘Author: Samita Bhuyan‘Date: 31-10-2000

‘Tested By: Manoranjan Mishra and Samita Bhuyan

‘Date of Test: 03-11-2000

‘Modified by:

‘Date of Modification:

‘Purpose of Modification:

All the parameters and the return type should be followed by one line description of the purpose of the parameter

• Body comments: Body comments though play an important role but too many can decrease the readability of the code. So body comments should be given to provide information on "what" and "why" but not on "how"
• Variable comments: Variable commenting though usually ignored, but are sometime necessary and are considered as a good coding style. When proper naming conventions are used then the meaning of the variable can be understood from its name and thus use of proper naming conventions should always be preferred than giving comments to each variable.

18.2 Programming Standards

The programming standards to be followed are as follows:

• use of proper indenting
• "option explicit" should be set at the module level to enforce explicit declaration of all variables in the module
• the scope of variables should be minimized
• all variables should be declared at the beginning
• one routine should be used for one purpose only
• the name of routines should specify their purpose
• using variables for different purposes, having the same name should be avoided
• one exit point should be there in a routine for better understandability
• value of the function should be assigned at the end of the function to enforce one exit point from the function
• routines should be ordered alphabetically
• use of magic numbers should be avoided

Example: Instead of using "Screen.Mousepointer = 11", "Screen.Mousepointe = vbHourglass" should be used.

18.3  Syntax Standards

Syntax standards make the application code more consistent and ensure that all the programmers follow the same standards. The standards to be followed are as follows:

• the "." operator should be used for any controls on the form, i.e., form.control rather than using form!control
• the "!" operator should be used for collection look-up
• the line continuation character, i.e., should be used for long lines
• ensure that the lines in the code fit into the code window
• multiple statements should not be written on the same line
• the return data type for all functions and Property Get procedures should be explicitly stated to ensure that the default data type of Visual Basic, i.e., variant is not returned
• multiple declarations should not be put on the same line

Example: Dim a, b, c, As String.

This line appears to be declaring three variables of type string but it actually declaring the first two variables, i.e., as of type variant and only the last variable, i.e., as of type string.

• the scope of the function, i.e., if it is private or public should be explicitly specified
• the operator "&" should be used for concatenating strings rather than "+"
• the operator "+" should be used for working with numbers

These are the checklist  which should be used by the project desighners, code designers,Quality checking & testing  people. for quality checking.

Click hare to downloads checklist forms

Top

    Table of Checklists