Browse Prior Art Database

Method to use code quality metrics to aid debugging

IP.com Disclosure Number: IPCOM000194441D
Publication Date: 2010-Mar-24
Document File: 5 page(s) / 74K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention deals with providing a better user experience for debugging code by hinting at where bugs are most likely. Hints will be based on the code metrics as well as other metadata about code. Metadata about the code include the checkin history of it as well as the past bug reports. One of the most interesting example of this metadata is the author of the code.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 5

Method to use code quality metrics to aid debugging

Problem


Defects in software are costly to find and fix. After the defect is reported, the developer is responsible for reproducing the bug and finding the code at fault. This process is time-consuming, and the skill and expert knowledge of determining where to look for a given bug often has to be developed anew for each project. If developers had some reliable suggestions as to where a bug is likely to reside, the debugging time could be reduced dramatically resulting in significant cost reduction.

Currently there are several ways to 'measure' code including static code analysis metrics, process metrics, and software metrics. These metrics assess the complexity and quality of code by analyzing the code structure, naming and commenting amounts, for example. Also, there are code coverage tools that determine how well-tested the code is by analyzing which parts of the code get exercised by automated tests. Higher scores on these metrics will tend to mean fewer bugs in the code.

A promising new area of research is to take into account the change history. This has proven to be a slightly better indicator then software metrics alone. However, the current state of the art only takes into account very limited information about the change: what was changed. And, the prediction of defects not as reliable as it could be.

Change history is only one aspect to the metadata of source code. The complete metadata of the source code brings a more complete picture and thus can provide a better prediction to where defects will occur. Furthermore, there is not a good user experience for presenting the likelihood of a defect to the programmer.

Note: The term "code section" throughout this article refers to a discrete amount of code. This may consist of: a line, code between squiggly brackets, method, class, file, package, component, repository, etc.

Core Idea


This invention deals with providing a better user experience for debugging code by hinting at where bugs are most likely. Hints will be based on the code metrics as well as other metadata about code. Metadata about the code include the checkin history of it as well as the past bug reports. One of the most interesting example of this metadata is the author of the code. This invention describes a way for businesses to save time and money by suggesting where in code a defect might occur.

The user experience is different for role of finding the defects and the role of managing the project. Only the prediction of a bug is necessary for the defect solver. However, for the manager of the project, why a section of a code may contain defects is of more importance.

Provide notification to the developer on bug likelihood for sections of code .

The developer has to go through huge amounts of stack trace to figure out where the

1

Page 2 of 5

                                           different notifications can be shown at different parts in the code. These notifications can consist of: background col...