Software defect indicator: Difference between revisions

Revision as of 16:53, 15 May 2009

Latest revision as of 02:58, 1 December 2023

(5 intermediate revisions by 5 users not shown)

Line 1:

A '''Software Defect Indicator''' is a pattern whichthat can be found in [[source code]] whichthat is strongly correlated with a [[software defect]], an error or omission in the source code of a computer program that may cause it to malfunction. When inspecting the source code of [[computer program]]s, it is not always possible to identify defects directly, but there are often patterns, sometimes called [[anti-pattern]]s, indicating that defects are present.

When inspecting the source code of [[computer program|computer programs]], it is not always possible to identify defects directly, but there are often patterns (sometimes called [[anti-pattern|anti-patterns]] indicating that defects are present.

Some examples of Software Defect Indicators:

* 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 reenabledre-enabled.

* Routine Too Complex: A program (method, module, routine, subroutine, procedure, or any named block of code) contains more than 10 binary terms in conditional statements.<ref>William T. Ward: "Software Defect Prevention Using McCabe's Complexity Metric", ''Hewlett-Packard Journal'', April 1989, pp 64-69: Control-flow complexity has been correlated with low reliabiltyreliability and frequent errors.</ref>

* Unused Variables: There are unreferenced variables in the code. Unreferenced variables are a strong indicator for other errors.<ref>David N. Card, Victor E. Church, and William W. Agresti: "An Empirical Study of Software Design Practices", ''IEEE Transactions on Software Engineering'', SE-12, no. 2, February 1986, pp 264-71: 46 percent of routines with no unused variables had no errors compared to only 17 to 29 percent for those with one or more unreferenced variables.</ref>

* Routine Too Complex: A program (method, module, routine, subroutine, procedure, or any named block of code) contains more than 10 binary terms in conditional statements.<ref>William T. Ward: "Software Defect Prevention Using McCabe's Complexity Metric", ''Hewlett-Packard Journal'', April 1989, pp 64-69: Control-flow complexity has been correlated with low reliabilty and frequent errors.</ref>

* Number of Distinct Committers: The amount of unique developers that have made contributions to a project's commit history. This is a process metric that is useful in indicating software defects. <ref>Madeyski, Lech, and Marian Jureczko. “Which Process Metrics Can Significantly Improve Defect Prediction Models? An Empirical Study.” Software Quality Journal 23.3 (2015): 393–422. Web.</ref>

* Unused Variables: There are unreferenced variables in the code. Unreferenced variables are a strong indicator for other errors.<ref>David N. Card, Victor E. Church, and William W. Agresti: "An Empirical Study of Software Design Practices", ''IEEE Transactions on Software Engineering'', SE-12, no. 2, February 1986, pp 264-71: 46 percent of routines with no unused variables had no errors compared to only 17 to 29 percent for those with one or more unreferenced variables.</ref>

==References==

{{reflist}}

==See also==

* [[Cyclomatic Complexitycomplexity]]

* [[Anti-pattern]]

* [[Computer program]]

Line 20 ⟶ 14:

* [[Control flow]]

* [[Software engineering]]

==References==

{{reflist}}

==External links==

*[https://web.archive.org/web/20070521072828/http://hissa.ncsl.nist.gov/sw_assurance/strtest.html NIST Special Publication 500-235 Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric]

[[Category:Software metrics]]