2
\$\begingroup\$

Please post your nominations for Best of Code Review 2013 — Night and Day category: The most dramatic improvement.

In your nomination post, be sure to include a link to the answer, as well as a short explanation of how the improvements are exceptional. One nomination per post, please. Answers being nominated must date from 2013.

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

How to make inverse Burrows-Wheeler Transform faster?

Simpler, shorter, and 36,000 times faster!

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

Retrieving the most recent communication from a user, and its accepted answer.

The original SQL query was an incomprehensible monster, including

  • A main query ("A"), containing an inner query ("B") named AggregatedData with an attribute name maxmaxtime, which in turn used a UNION of two queries ("C1" and "C2"), also known as kk and MaximumUserTime respectively
  • Two uses of SELECT DISTINCT to deduplicate subquery results
  • The query parameter @UserId mentioned four times

It languished as tumbleweed for over two years, probably mostly due to its complexity.

The solution clears up the query by introducing terminology that matches the way users normally think of messages: threads and interlocutors. It goes on to suggest a VIEW that could simplify the query, as well as pointing out a dramatic simplification that could be possible using another RDBMS such as PostgreSQL.

By the way, even though the code in the question was a mess, the question was very well composed, including the background, schema, example data, and expected output.

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

Vending machine implementation, and its accepted answer.

The original question contained code that:

  • Didn't use arrays

  • Didn't use loops (instead used if statements that all did the same thing)

  • Didn't display output properly

  • Included an off-by-one error

  • Didn't check the bounds of the entered number

  • Wasted memory

The answer corrected all of these problems and went a little further to correct some of the style problems in the original code.

This question and answer duo reached the top of the Hot Network Questions shortly after they were both posted.

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

Refactoring chart generator in Linq, and its accepted answer.

Refactoring a big, smelly pile of nested switch blocks turned a monster consoller method into a much more readable 4-liner.

2013 has seen a number of if/switch posts in , I'm nominating this one specifically because both the question and answer are very focused on the switch block, and the OP has appended their 4-liner refactored code to the original question. I think it's representative enough that in future answers where it would be applicable, I might just link to that post instead of re-explaining the Dictionary thing.

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

Optimizing this seemingly slow Query

SQL is often easy to get lost in, and, in this case, it appears that the OP got lost in some perceived issue with 'Outer Joins', and 'overthinking' the problem. The result was a massively complicated query with sub-selects, outer joins, and conditions which, in the end, because of the outer-joins, have no impact on the actual results.

Eliminating the cruft, the results are hugely simpler, and faster.

\$\endgroup\$

You must log in to answer this question.

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