Editing Software bug (section)

== Prevention ==

[[File:Software bug displayed on two screens at La Croix de Berny station in France - 2021-10-28.jpg|thumb|Error resulting from a software bug displayed on two screens at [[La Croix de Berny station]] in France]]

Preventing bugs as early as possible in the [[software development process]] is a target of investment and innovation.<ref>{{cite book
|title=Automated Defect Prevention: Best Practices in Software Management
|author1=Dorota Huizinga
|author2=Adam Kolawa
|isbn=978-0-470-04212-0
|date=September 2007
|publisher=Wiley-IEEE Computer Society Press
|url=https://ieeexplore.ieee.org/book/5201515}}</ref><ref>{{cite book | last = McDonald | first = Marc | author2 = Musson, Robert | author3 = Smith, Ross | title = The Practical Guide to Defect Prevention | url = https://archive.org/details/practicalguideto00/page/480 | year = 2007 | publisher = Microsoft Press | page = [https://archive.org/details/practicalguideto00/page/480 480] | isbn = 978-0-7356-2253-1 | df = mdy-all | url-access = registration }}</ref>

=== Language support ===

Newer [[programming language]]s tend to be designed to prevent common bugs based on vulnerabilities of existing languages. Lessons learned from older languages such as [[BASIC]] and [[C (programming language)|C]] are used to inform the design of later languages such as [[C Sharp (programming language)|C#]] and [[Rust (programming language)|Rust]].

A [[compiled]] language allows for detecting some typos (such as a misspelled identifier) before [[Runtime (program lifecycle phase)|runtime]] which is earlier in the [[software development process]] than for an [[Interpreter (computing)|interpreted]] language.

Languages may include features such as a static [[type system]], restricted [[namespace]]s and [[modular programming]]. For example, for a typed, compiled language (like [[C (programming language)|C]]):

 float num = "3";

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 is generally fast, but is considered dangerous; relatively likely to cause a major bug. 

Some languages include features that add runtime overhead in order to prevent some bugs. For example, many languages include runtime [[bounds checking]] and a way to handle out-of-bounds conditions instead of crashing.

=== Techniques ===

Programming techniques such as [[programming style]] and [[defensive programming]] are intended to prevent typos.

For example, a bug may be caused by a relatively minor typographical error (typo) in the code. For example, this code executes function {{code|foo}} only if {{code|condition}}is true.

 if (condition) foo();

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

 if (condition); foo();

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.

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

=== Agile practices ===

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

Tools to monitor the performance of the software as it is running, either specifically to find problems such as [[Bottleneck (engineering)|bottlenecks]] or to give assurance as to correct working, may be embedded in the code explicitly (perhaps as simple as a statement saying <code>PRINT "I AM HERE"</code>), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

=== Open source ===

[[Open source]] development allows anyone to examine source code. A school of thought popularized by [[Eric S. Raymond]] as [[Linus's law]] says that popular [[open-source software]] has more chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow".<ref>[http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html "Release Early, Release Often"] {{webarchive|url=https://web.archive.org/web/20110514032650/http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html |date=May 14, 2011 }}, [[Eric S. Raymond]], ''[[The Cathedral and the Bazaar]]''</ref> This assertion has been disputed, however: computer security specialist [[Elias Levy]] wrote that "it is easy to hide vulnerabilities in complex, little understood and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so."<ref>[http://www.securityfocus.com/news/19 "Wide Open Source"] {{webarchive|url=https://web.archive.org/web/20070929105937/http://www.securityfocus.com/news/19 |date=September 29, 2007 }}, [[Elias Levy]], ''SecurityFocus'', April 17, 2000</ref> An example of an open-source software bug was the [[Debian#2008 OpenSSL vulnerability|2008 OpenSSL vulnerability in Debian]].