C++/C# bad practices: learn how to make a good code by bad example

If something strange is happening to your PC, check its memory

A typical situation – your program is not working properly. But you have no idea what’s going on. In such situations we recommend not rushing to blame someone, but focus on your code. In 99.99% of cases, the root of the evil is a bug that was brought by someone from your development team. Very often this bug is really stupid and banal. So go ahead and spend some time looking for it!

The fact that the bug occurs from time to time means nothing. You may just have a Heisenbug

Blaming the compiler would be an even worse idea. It may do something wrong, of course, but very rarely. It will be very awkward if you find out that it was an incorrect use of sizeof(), for example. We have an article about that: The compiler is to blame for everything

But to set the record straight, we should say that there are exceptions. Very seldom the bug has nothing to do with the code. But we should be aware that such a possibility exists. This will help us to stay sane.

We’ll demonstrate this using an example of a case that once happened with one developer. Fortunately, we have the necessary screenshots.

He was making a simple test project that was intended to demonstrate the abilities of the Viva64 analyzer (the predecessor of PVS-Studio), and this project was refusing to work correctly.

After long and tiresome investigations, he saw that one memory slot is causing all this trouble. One bit, to be exact. You can see on the picture that he is in the debug mode, writing the value “3” in this memory cell.

After the memory is changed, the debugger reads the values to display in the window, and shows number 2: See, there is 0x02. Although I’ve set the “3” value. The low-order bit is always zero.

A memory test program confirmed the problem. It’s strange that the computer was working normally without any problems. Replacement of the memory bank finally let the program work correctly.

He was very lucky. He had to deal with a simple test program. And still he spent a lot of time trying to understand what was happening. He was reviewing the assembler listing for more than two hours, trying to find the cause of the strange behavior. Yes, he was blaming the compiler for it.

Recommendation

Always look for the error in your code. Do not try to shift responsibility.

However, if the bug reoccurs only on your computer for more than a week, it may be a sign that it’s not because of your code.

Keep looking for the bug. But before going home, run an overnight RAM test. Perhaps, this simple step will save your nerves.

Written by Andrey Karpov.This error was found with PVS-Studio static analysis tool.