Software bug: Difference between revisions

Content deleted Content added
review: syntax hilighting. add link, clarification.
m Static analysis: remove user name comment
 
(11 intermediate revisions by 7 users not shown)
Line 24:
|date=December 31, 1990
|isbn=978-0-7381-0391-4
|doi=10.1109/IEEESTD.1990.101064}}</ref>{{rp|31}}anomaly,<ref name=ieeeGlossary/>{{rp|10}} fault,<ref name=ieeeGlossary/>{{rp|31}} failure,<ref name=ieeeGlossary/>{{rp|31}} error,<ref name=ieeeGlossary/>{{rp|31}} exception,<ref name=ieeeGlossary/>{{rp|31}} crash,<ref name=ieeeGlossary/>{{rp|22}} glitch, bug,<ref name=ieeeGlossary/>{{rp|14}} defect, incident,<ref name=ieeeGlossary/>{{rp|39}} or side effect.
|doi=10.1109/IEEESTD.1990.101064}}</ref>{{rp|31}}
anomaly,<ref name=ieeeGlossary/>{{rp|10}}
fault,<ref name=ieeeGlossary/>{{rp|31}}
failure,<ref name=ieeeGlossary/>{{rp|31}}
error,<ref name=ieeeGlossary/>{{rp|31}}
exception,<ref name=ieeeGlossary/>{{rp|31}}
crash,<ref name=ieeeGlossary/>{{rp|22}}
glitch,
bug,<ref name=ieeeGlossary/>{{rp|14}}
defect,
incident,<ref name=ieeeGlossary/>{{rp|39}}
or side effect.
 
==Examples==
Line 80 ⟶ 69:
}} (linked from [https://insights.sei.cmu.edu/library/news-at-sei-1999-archive/ News at SEI 1999 Archive])</ref>
 
Some contend that ''bug'' may be used to [[coverup|cover up]] an intentional design decision. In 2011, after receiving scrutiny from US Senator [[Al Franken]] for recording and storing users' locations in unencrypted files,<ref>{{cite journal
|author=Gregg Keizer
|title=Apple faces questions from Congress about iPhone tracking
Line 118 ⟶ 107:
is syntactically correct, but fails type checking since the right side, a string, cannot be assigned to a float variable. Compilation fails {{endash}} forcing this defect to be fixed before development progress can resume. With an interpreted language, a failure would not occur until later at runtime.
 
Some languages exclude features that easily lead to bugs, at the expense of slower performance {{endash}} the principle being that it is usually better to write simpler, slower correct code than complicated, buggy code. For example, the [[Java (programming language)|Java]] does not support [[pointer (computer programming)|pointer]] arithmetic which iscan generallybe very fast, but ismay consideredlead dangerous;to relatively[[memory likelycorruption]] toor cause[[Segmentation afault|segmentation majorfaults]] bug.if not used with great caution.
 
Some languages include features that add runtime overhead in order to prevent somecommon bugs. For example, many languages include runtime [[bounds checking]] and a way to handlerecover from out-of-bounds conditionserrors instead of crashing.
 
=== Techniques ===
 
Programming techniques such as [[programming style|Style guidelines]] and [[defensive programming]] arecan intendedprevent easy-to-miss preventtypographical errors (typos).
 
For example, amost bug[[List_of_C-family_programming_languages|C-family mayprogramming belanguages]] causedallow bythe aomission relativelyof minor,braces [[typographicalaround error]]an ininstruction sourceblock code.if Forthere's only a single instruction. example,The thisfollowing code executes function {{code|foo}} only if {{code|condition}} is true.:
 
<syntaxhighlight lang="c"> if (condition) foo();</syntaxhighlight>
foo();
 
But this code always executes {{code|foo}}:
 
<syntaxhighlight lang="c"> if (condition); foo();</syntaxhighlight>
foo();
 
Using braces - even if they're not strictly required - reliably prevents this error:
A convention that tends to prevent this particular issue is to require braces for a block even if it has just one line.
 
if (condition) {
<syntaxhighlight lang="c">
if foo(condition) {;
foo();
}
</syntaxhighlight>
 
Enforcement of conventions may be manual (i.e. via [[code review]]) or via automated tools.<!-- such as [[User:Kvng/RTHLint_(software)|linters]]-->.
 
=== Specification ===
 
Some{{who?|date=May 2025}} contend that writing a [[program specification]], which states the intended behavior of a program, can prevent bugs. Others{{who?|date=May 2025}}, however, contend that formal specifications are impractical for anything but the shortest programs, because of problems of [[combinatorial explosion]] and [[Nondeterministic algorithm|indeterminacy]].
 
Some contend that formal specifications are impractical for anything but the shortest programs, because of problems of [[combinatorial explosion]] and [[Nondeterministic algorithm|indeterminacy]].
 
=== Software testing ===
 
One goal of [[software testing]] is to find bugs. Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.{{citation needed|date=February 2017}}
One goal of [[software testing]] is to find bugs.
 
Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.{{citation needed|date=February 2017}}
 
=== Agile practices ===
Line 160 ⟶ 145:
[[Agile software development]] may involve frequent software releases with relatively small changes. Defects are revealed by user feedback.
 
With [[test-driven development]] (TDD), [[unit test]]s are written while writing the production code, and the production code is not considered complete until all tests have been written and complete successfully.
 
=== Static analysis ===
 
Tools for [[static code analysis]] help developers by inspecting the program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see [[halting problem]]), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software.
 
=== Instrumentation ===
Line 223 ⟶ 208:
=== Severity ===
 
''Severity'' is a measure of impact the bug has.<ref>{{Cite journal|last1=Soleimani Neysiani|first1=Behzad|last2=Babamir|first2=Seyed Morteza|last3=Aritsugi|first3=Masayoshi|date=2020-10-01|title=Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584920301117|journal=Information and Software Technology|language=en|volume=126|pages=106344|doi=10.1016/j.infsof.2020.106344|s2cid=219733047|url-access=subscription}}</ref> This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized, but differ by context such as industry and tracking tool. For example, a crash in a video game has a different impact than a crash in a bank server. Severity levels might be ''crash or hang'', ''no workaround'' (user cannot accomplish a task), ''has workaround'' (user can still accomplish the task), ''visual defect'' (a misspelling for example), or ''documentation error''. Another example set of severities: ''critical'', ''high'', ''low'', ''blocker'', ''trivial''.<ref>{{cite web|url=http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|title=5.3. Anatomy of a Bug|work=bugzilla.org|url-status=live|archive-url=https://web.archive.org/web/20130523121753/http://www.bugzilla.org/docs/4.4/en/html/bug_page.html|archive-date=May 23, 2013}}</ref> The severity of a bug may be a separate category to its priority for fixing, or the two may be quantified and managed separately.
 
{{anchor|Show stopper|Showstopper|Showstopper bug}}A bug severe enough to delay the release of the product is called a ''show stopper''.<ref name="DoD_Glossary1989">{{Cite encyclopedia |title=Show stopper |encyclopedia=Glossary: defense acquisition acronyms and terms |year=1989 |publisher=Department of Defense, [[Defense Systems Management College]] |___location=Fort Belvoir, Virginia|url=https://hdl.handle.net/2027/mdp.39015061290758?urlappend=%3Bseq=163 |editor-last=Jones |editor-first=Wilbur D. Jr. |edition=4 |page=123 |hdl=2027/mdp.39015061290758?urlappend=%3Bseq=163 |language=en|via=Hathitrust}}</ref><ref name="Zachary1994">{{Cite book |title=Show-stopper!: the breakneck race to create Windows NT and the next generation at Microsoft |last=Zachary |first=G. Pascal |publisher=[[Free Press (publisher)|The Free Press]] |year=1994 |isbn=0029356717 |___location=New York |page=158 |language=en |url=https://archive.org/details/showstopperbreak00zach/page/158/mode/1up?q=%22showstopper+bug%22 |url-access=registration |via=archive.org}}</ref>
Line 265 ⟶ 250:
=== Cost ===
 
In 1994, NASA's [[Goddard Space Flight Center]] managed to reduce their average number of errors from 4.5 per 10001,000 lines of code ([[Source lines of code|SLOC]]) down to 1 per 1000 SLOC.<ref name=NASA1994>{{cite journal
|journal=Software Engineering Laboratory Series
|title=An Overview of the Software Engineering Laboratory
Line 279 ⟶ 264:
|series=NASA Office of Chief Engineer Technical Excellence Program
|url= https://www.nasa.gov/wp-content/uploads/2015/04/418878main_fswc_final_report.pdf
}}</ref> Some projects even attained zero defects: the [[firmware]] in the [[IBM Wheelwriter]] typewriter which consists of 63,000 SLOC, and the [[Space Shuttle]] software with 500,000 SLOC.<ref name="CobbMills1990" />
}}</ref>
Some projects even attained zero defects: the [[firmware]] in the [[IBM Wheelwriter]] typewriter which consists of 63,000 SLOC, and the [[Space Shuttle]] software with 500,000 SLOC.<ref name="CobbMills1990" />
 
=== Benchmark ===