: This article is written solely for fun. Do not try to repeat it at work. However, do whatever you want at home. Disclaimer We, developers, come across regularly, it's just part of our job. Therefore, at first glance, the question “Can you make a bug on purpose?” may seem banal - “Yes, of course, I can write a bug.” However, if you think about it, everything doesn't seem so obvious anymore. bugs The fact is that the . A bug is an error, a flaw in a generally bug is not the same as broken code working program. The term "bug" in the context of software issues originated in 1947 when a moth caused a malfunction in the Harvard Mark II computer. The engineers literally found a moth stuck in one of the relays, and they referred to it as the "first actual case of bug being found.” What’s the problem? The world is known to be well described by mathematics formulas. And the formulas are actually the algorithms. Therefore, if we were able to describe some phenomenon mathematically, then correcting the resulting formula so that it gives the wrong result is a non-trivial task. Nevertheless, it’s not time to despair. may come to help us here. We have all seen these . There's always something wrong with the boundaries 🤷♀️. So, let’s note the first idea for creating a bug - . only sometimes Boundary conditions if index == 0 {…} else if index == n-1 {…} ignore edge cases In general, iterating through arrays is a storehouse of potential bugs. And the most common of them is . If you have never stumbled upon such a thing, you have never coded. Unfortunately, this bug is so popular that people began to write safe wrappers for arrays, something like . So today, your colleagues will hardly approve any code without this thing. You can try, but it's unlikely… index out of bounds array[safe: index] Prevalent bugs include . A recursive algorithm can recur infinitely when there is no exit condition. Recursion seems optional here - write , and you're done. However, again, the popularity of the bug is playing against us. The developers are well aware of the potential problems of endless loops, and their eyes will definitely catch on to something like this at the code-review 👮 stack overflow while true To still push your insidious plan into production, try using . a global variable for exit conditions and quietly change it from the outside var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } } General advice It's funny that even ChatGPT refuses to help when it comes to writing bugs. Maybe I just need a premium subscription… 🤔 Being on the bright side, offers a set of general rules that contribute to writing bugs-free code: сode in small Increments, follow coding standards, write unit tests, and bla-bla-bla. We can try to do the opposite thing - write spaghetti code and forget about SOLID. However, this way, we write. Instead of an elegant pinpoint weapon, we get unmanageable chaos, which will conquer our program. AI we lose control over all the code When solving the problem of creating a bug, it is worth determining the subtasks. First, we need to come up with some rare edge cases. Secondly, we need to disguise the bug as regular code so that it passes the code review. Thirdly, we have to blunt the attention of the QA department. Fourth, don't get caught right away. But this is already optional. My general advice is as follows (and you share yours in the comments): . To double back, change the values of important parameters from the most unexpected places. Do this through several classes as if you were a VPN. Manipulate the access level Implement some unexpected logic in the child class. In short, . break the L principle in SOLID class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } } Hide your insidious changes in bigger functions. - get lost in the crowd. The more lines, the better Use the same principle in pull requests. In a small PR, the probability of being noticed is higher. Try to break the bug into parts and put them in . If possible, then also to different reviewers. different pull requests Find the weaknesses of your QA and win his trust. Or distract them with conversations during the check. By the way, have you heard of Heisenbug? This is a bug that disappears or changes its behavior during research/ . Like Schrodinger's cat. Perfect if the fix issue will not be assigned to you. debugging One common example of a heisenbug is a bug that appears when the program is compiled with an optimizing compiler, but not when the same program is compiled without optimization (as is often done for the purpose of examining it with a debugger). While debugging, values that an optimized program would normally keep in registers are often pushed to the main memory. You can Believe in yourself! History knows examples of when a bug was admitted to production in very serious companies. One of the most expensive software bugs occurred in 1996 when the Ariane 5 rocket, carrying the Cluster mission, exploded just 40 seconds after liftoff. The failure was traced back to a software bug in the rocket's guidance system. Ariane 5 Flight 501: In 1999, NASA lost the Mars Climate Orbiter due to a software error. The software used imperial units (pound-seconds) instead of metric units (newton-seconds), causing the spacecraft to burn up in the Martian atmosphere. NASA's Mars Climate Orbiter: Moreover, some bugs can become features, like a wall-jumping in or Mahatma Gandh behavior in …probably. Mario Civilization Developing a bug is the ability to think through your algorithm and anticipate possible problems thoroughly. So, even if you have no reason to leave a bug in the code, it's still worth considering.
