Hacker News Reader

Comment by didgetmaster | Hacker News Reader

Even very senior engineers can make simple mistakes that can bruise their egos. Several years ago I was called into the office of the chief architect. I was also a senior engineer with a lot of experience, but he was quite famous (at the time) in the industry for his technical skill. He was convinced he had found a compiler bug. He had some c code that he had traced through the debugger at the assembly level. It was something like this:

if(/some really long boolean value with AND and OR clauses/); { /* some code to execute if TRUE */ }

He was sure that the if statement was FALSE some of the time, but the code inside the brackets would always execute. He spent more than an hour pouring over the code.

It took me a few minutes before I noticed the semicolon at the end of the if statement. I'm sure he felt stupid when I pointed it out.

View on HN

> I'm sure he felt stupid when I pointed it out.

He certainly did. There is no amount of experience that makes people not feel stupid about those. What changes is that you learn to not be affected by it, because you know that it's not a personal flaw (at least not one specific to you), and while you can improve on it, you can't completely fix it.

But the alternating between feeling like the dumbest person on Earth and the smartest person on Earth never goes away.

You develop tunnel vision and, whether someone points it out to you or you look at it with fresh eyes in the morning, it's a head slap "Duh."

Yep. I've learned over time to just walk away from problems like this that make me go "that's not possible!" or "there must be a compiler bug!"

After at least a few hours away (ideally not coding) your fresh eyes will often spot it.

Similarly, demoing the bug to someone else is a good way, and often through the mere act of demoing it you'll find it yourself (also known as "rubber ducking" [1]).

[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging

Or just better software development practices that can eliminate whole classes of bugs. If the developer was instead in the habit of not putting huge expressions inside if() statements, he might have caught it himself. Consider:

    bool condition = /some really long boolean value with AND and OR clauses/;
    if(condition); { /* some code to execute if TRUE */ }

Two advantages of doing it this way:

1. It's much easier to notice that incorrect semicolon

2. Even if you don't, you can stick a breakpoint (or log) between when condition is set and when it is evaluated, to convince yourself it works.

3. All modern compilers will produce the exact same code as they produce with it mashed into the if()

I agree. It also really helps when you want to negate something.

if(!condition) is a much better read and less prone to errors than trying to negate a long statement inside the if().

This pattern also eliminates duplication. I have fixed bugs in code where the same long if condition was duplicated several times within the same function (probably with cut and paste). This wastes cycles recalculating it each time and runs the risk of changing one of them without changing them all.

    bool subCondition1 = /* something kinda long */;
    bool subCondition2 = /* something also kinda long */;
    bool subCondition3 = /* something absurdly long */;
    bool condition = (subCondition1 && subCondition2) || subCondition3;

    if (condition) {
      /* do something */
    }

where, ideally, the sub conditions all have meaningful, relevant names that succinctly express what they were testing for.

Good point, code readability is often the best thing to optimize for.

Your change also got me thinking of unit tests: at some point it becomes worthwhile to have dedicated tests on that condition, and that's often easiest by putting it in a static method, and that also improves readability.

In those situations i do feel stupid but also feel relieved. Fixing a semi-colon is easier than fixing some major logic flaw that could have way deeper and worse ramifications.

I think it happened enough that some newer compilers actually post a warning message when it is encountered. Just like switch statements when you don't have a break; statement for every case: clause. In some cases you want the logic to fall through, but it can cause havoc when you didn't want that and you just forgot the break.

Reply on news.ycombinator.com