Software bug: Difference between revisions

Revision as of 12:43, 6 May 2025

Latest revision as of 06:34, 18 July 2025

(5 intermediate revisions by 4 users not shown)

Line 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 minorbraces typographicalaround erroran (typo)instruction inblock theif code.there's Foronly a single instruction. example,The thisfollowing code executes function {{code|foo}} only if {{code|condition}} is true.:

if (condition)
foo();

But this code always executes {{code|foo}}:

if (condition);
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) {

foo();

}

Enforcement of conventions may be manual (i.e. via [[code review]]) or via automated tools such as [[Lint_(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]].<!--[[User:Kvng/RTH]]-->

=== 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 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 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>