IfSQ

IfSQ Level-2: A Foundation-Level Standard

The IfSQ Level-2 Standard for Computer Program Source Code adds an additional set of defect indicators to those contained in Level-1 to create a more comprehensive measure of software quality.

Aside from the additional defect indicators, there are two main differences between Level-1 and Level-2. Firstly, the two standards require differing levels of expertise in order to identify defects. The defect indicators in Level-1 are sufficiently obvious and easy to identify that anyone, regardless of programming experience, is able to perform a Level-1 assessment. The Level-2 standard on the other hand requires a more advanced level of programming knowledge and experience.

Secondly, whereas Level-1 is essentially objective in its assessment, in Level-2 we actively promote discussion between the assessor and the programmer, by requiring the assessor to use his professional judgement to look for and identify potential issues, which we refer to as Causes for Concern (CfCs) and to resolve his concerns directly with the programmer.

The Level-2 Standard is still concise enough, however, that an assessment can be performed quickly by an individual. Level-2 inspections are extremely cost-effective because the savings made by finding defects early greatly outweigh the costs of the assessment.

In the Level-2 Standard, we look for the following defect indicators:

• Work In Progress
  • WIP-1—Vague "To Do": A programmer has left a note to himself or his colleague indicating that a piece of work needs to be done. However it is clear that the work has not been carried out, and there is no indication as to when or why that work needs to be done.
  • WIP-2—Disabled Code: Code has been written and the programmer has disabled it, or switched it off, without making it clear why it has been disabled, or when or whether it will be reenabled.
  • WIP-3—Empty Statement Block: The programmer has left a statement block or placeholder empty. When a programmer designs a program top-down he will often first outline the structure of the program in the form of statement blocks and fill in the content of each block in the course of his work. An empty statement block therefore indicates that there may be missing logic and that some extra code may be required.
• Structured Programming
  • SP-1—Routine Too Long: Routines longer than 150 lines (excluding comments and blank lines) have been shown to be less stable, more subject to change, and more expensive to fix than shorter routines.
  • SP-2—Nesting Too Deep: Studies have shown that few people can understand nesting of conditional statements to more than 3 levels.
  • SP-3—Routine Too Complex: Control-flow complexity has been correlated with low reliabilty and frequent errors.
• Single Point of Maintenance
  • SPM-1—Magic Numbers: Numeric literals (other than 0 or 1) have been hard-coded into the body of a program.
  • SPM-2—Magic Strings: A string literal has been hard-coded into a statement that influences the flow of a program.
  • SPM-3—Copy/Paste Programming: An identical or largely similar section of code appears in two or more places in the same source code file.
• Defensive Programming
  • DP-1—Parameter Not Checked: A parameter received by a program is used without first checking if its contents are present and within the expected range.
  • DP-2—Status Ignored After Call: Error status codes or exceptions from the run-time environment are suppressed or ignored, masking internal processing errors.
  • DP-3—Unexpected State Not Trapped: Part of a program that uses a value to switch between different branches does not trap unexpected cases.
• Causes for Concern
  • CfC-NC—Not Complete: Some element or functionality appears to be missing from the program.
  • CfC-WR—Wrong Result: Some part of the program looks likely to produce an incorrect result.
  • CfC-HtM—Hard to Maintain: There are indications that the program will be unnecessarily difficult to maintain.