12
\$\begingroup\$

Please post your nominations for the Best of Code Review 2014 - Exterminator category.

Answer that points out the most interesting obscure bug in the original code.

In your nomination post, please make sure to include a link to the nominated answer, as well as a short explanation of what makes that post worthy of being nominated in this category, and why it should win over the others.


Small characters at the bottom: Only one nomination per post, nominated answers must have a creation date in 2014, downvotes don't count, and Santa reserves the right to award the top-voted nominee a special bounty as a token of appreciation on behalf of the Code Review community.

\$\endgroup\$

8 Answers 8

8
\$\begingroup\$

Edward on "Calculating the harmonic average"

The original assembly language code was not bad when it was posted, but with certain inputs, such as the integers from 1 to 100,000, it was inaccurate by only 0.2%, dependent on the ordering of the data, making this a very subtle bug.

It also cited Goldberg's seminal paper What Every Computer Scientist Should Know About Floating-Point Arithmetic and illustrates, with sample code, why this is important.

\$\endgroup\$
0
5
\$\begingroup\$

Simon André Forsberg on "Find Min of 3 Numbers hardcoded"

This answers found an obscure bug that was at least partially caused by poor code readability. Not only does the answer point out the bug and several failing test cases, but it also provided a solution to the problem. This is what Code Review is all about and definitely one of the best answers of 2014.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ It is also one of the only two answers (the other being skiwi's) that actually comments about the existing code and not only says "this is how I would do it". \$\endgroup\$ Commented Jan 4, 2015 at 14:36
5
\$\begingroup\$

200_success on "Convert number into hours : minutes"

To be honest, I stumbled upon this bug accidentally by carelessly introducing a bug of my own. My original answer, which used date.getHours(), produced nonsense — which @Geo242 rightfully complained about. While fixing the bug that I introduced, it occurred to me that the date.getMinutes() in the original question was also wrong for the same reason.

I nominate this bug because of

  • its collaborative and serendipitous method of discovery
  • the fact that it manifests itself only in India, Sri Lanka, Afghanistan, Iran, Myanmar, Newfoundland, Venezuela, Nepal, the Chatham Islands, and parts of Australia.
\$\endgroup\$
4
\$\begingroup\$

Rolfl on "Regularity in 'The Rusty Towel of Mutual Understanding'"

The answer points out two subtle bugs

  • one in a random selection algorithm that skewed the "randomness" of the selection.

    So, you do have an imbalance. You are selecting people about 10% more often than you should....

  • the second bug is "Dagger" values like "The Dagger of Dread" being over-represented in the output. This came down to a wall-of-text bug, where "Dagger" appeared twice in a list of constants, and was hard to find:

    private static String[] items = { "Chainsaw", "Towel", "Ping-Pong Ball",
            "Longsword", "Scissors", "Dagger", "Blade", "Bow", "Axe", "Dagger",
            "Spoon", "Fork", "Coat", "Chain Mail", "Plate Mail", "Cloak",
            "Cape", "Mirror", "Cauldron", "Pouch", "Boots", "Shoes", "Greaves",
            "Pants", "Robes", "Locket", "Ring", "Amulet", "Potion", "Fish",
            "Teapot", "Hood", "Crown", "Cap", "Helmet" };
    

The answer details the exact cause of the bugs. These are the kind of bugs that can live in a code base undetected for years, so this is definitely a worthy nominee for "Exterminator of the Year".

\$\endgroup\$
3
\$\begingroup\$

Janos on "Code Kata - Berlin Clock"

Considering that a Berlin Clock itself is not very readable to begin with, it's probably no surprise that there would be obscure bugs in the implementation, overlooked by 4 other answers.

I found the bugs by implementing the examples given in the requirements as proper unit tests. By refactoring the code, while keeping the rest of the unit tests intact, the problem became clearer as the code became more readable.

\$\endgroup\$
2
\$\begingroup\$

200_success on "Tool for creating CR questions"

The tool was created for Code Review. The act of posting the code to Code Review created the bug. Code review by @200_success found the bug.

\$\endgroup\$
1
\$\begingroup\$

Janos on "Time to Next Departure"

The code was dependent on the current time, which made it hard to unit test, and hard to see a bug that would happen when the current time is 58 or 59 minutes, resulting in an infinite loop.

\$\endgroup\$
0
\$\begingroup\$

Janos on "Quicksort in Python"

There was an obscure off-by-one error, the first element of a list would not be sorted, for example for input:

[14, 3, 9, 2, 1, 5, 4, 2, 1, 3]

It gave output:

[14, 1, 1, 2, 2, 3, 3, 4, 5, 9]

The bug would have been easier to notice with better variable names, and of course unit tests.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .