What are the bugs

1. Some etymology and entomology
Let's look more closely at such a familiar and (painfully?) Native word BAG. It comes from the English word Bug, meaning "insect." There are still many third-party meanings, in particular, the English expression “to go bugs” - go crazy, which is easily correlated with a completely Russian “cockroaches in my head”. Also recalled and "bugs on the line" (also, by the way, in English - bugs). And again we came to the insects.

Back in 1878, Thomas Alva Edison (yes, the same one!) Wrote in letters to his comrade-in-arms, Puskasu: “ This is what I’ve got to know. and it’s certainly not been reached. ” In the same word, engineers also called failures of radar electronics during the Second World War. Of course, the more common story is that in 1946 the development of the Mark-2 computer (Mark-II) was suspended due to a malfunction caused by a moth hit between contacts. The corpse of the moth was removed and taped to the report with adhesive tape with the comment “First actual case of bug being found.”. As you might guess, from about the same place, “ears grow” and the words “debugger” are literally “a deliverer from bugs”.

2. Types of bugs.
The simplest (not as an infusoria slipper, but the easiest to understand, it is fashionable to say “classic”), a bug is a discrepancy between the expected result (PR) and the actual result (FR). Let's look at this with an example:

Actions	Expected Result	Actual result
Enter the expression "= 2 + 2 * 2" (without quotes) into the cell and press ENTER	6	8 BAG !!!!

(this is, by the way, the real bug of old Microsoft Excel - it did not take into account the priority of mathematical operations, according to which multiplication has the highest priority compared to addition)
')
It's simple. We are waiting for one thing - we get another. Bug
I will not list all sub-types of the classical bug - from typos in the data and typos in the code to infinite cycles, from using the assignment operator instead of the equality check operator to using an uninitialized variable, from race condition to multi-threaded applications to buffer overflow, and so further, and the like - all these are fairly mundane and clear phenomena. Let us turn to unfamiliar exoticism.

2.1. Heisenbug
A bug named after the Heisenberg Uncertainty Principle - the concept of quantum physics. A simple (even the word “simple” is not very applicable here) an example of such a bug will be an error that occurs when a program is launched for execution in a working environment, but disappears when a program is started in a debugger.

2.2. Borbag ​​(Bohrbug)
A type of bug named after the Bohr atomic model. In contrast to Heisenbagu, it manifests itself constantly under the same set of circumstances. The question is that the entire set of circumstances would be impossible (or very difficult) to trace.

2.3. Mandelbug
Named in honor of Benoit Mandelbrot, who made a huge contribution to the theory of fractals. Mandelbags call mistakes, whose reasons are so complex and unclear that they actually seem to be chaotic and not amenable to descriptions. (the keyword "seem"). This may be caused, for example, by a slow reaction of the system - that is, an error has already occurred, but you will find out only after some time, which will make it very difficult to localize the causes.

2.4. Schroedinbug
Shredinbag is named after the famous paradox with Schrödinger's cat (or is this poor animal - a cat?). It lies in the fact that someone reads the program code (which has been running for some time) and exclaims “Yes, this can not be! It simply cannot function! ”, After which the program ceases to function until this error is corrected. Being, it would seem, absolutely fantastic, this mistake comes across in reality - ask friends of veteran developers, they will confirm. Although, of course, the subsequent analysis, as a rule, makes it possible to attribute the error to sections 2.1, 2.2 or 2.3, this is not always possible.

2.5. Moon phases
In fact, such an error does not exist - this is a popular excuse for those who do not want (have no desire and / or time) to understand the complex causes of an error. However, in history there are a couple of examples where errors occurred literally due to the phases of the moon. I will not give these stories here, hoping that none of us will have to work with such complex devices. Nevertheless, in any case, I would like to warn everyone against indiscreet conclusions and ask them to be more attentive, persevering and scrupulous in their work.

2.6. Statistical (better known as quantitative) bug
The bug arising from the program a large number of any actions. An example of this error is the launch of a program that should evenly place a certain number of points on a plane. If, for example, when there are a large number of points, the program not only incorrectly positions them, but also strives to locate everything on one side of the plane (with up to a certain number of points working perfectly) - voila, a quantitative bug.

2.7. Demonstration effect.
And of course, the well-known to everyone, “the effect of the first show,” which happened more than once with your humble servant. As soon as it comes time to show, for example, a unit that was perfectly functioning on a test stand, something terrible is happening. Priichny, as a rule, trivial - the omission of "minor" test cases, inattention to detail and unrecorded juz cases. Again - be careful.

At this point I will finish a brief overview of the bugs, I will be glad to receive your comments and suggestions.