# Best of Code Review 2016 - Night and Day category

Please post your nominations for the Best of Code Review 2016 - Night and Day category.

The most dramatic improvement (nominate both the question with the most hopeless code and the answer that cleans it up the best).

In your nomination post, please make sure to include a link to the nominated answer. Include a short explanation of what makes the suggestions in the answer exceptional.

Small characters at the bottom: Only one nomination per post. Nominated answers must have a creation date in 2016. Downvotes don't count. 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.

## 2 Answers

I'll nominate Charmander Brainfuck interpreter in Haskell as well as my answer. The problem with the code in questions were that you've gained almost no readability compared to the original brainfuck-like code, and the interpreter had to parse the code several times. Also, most of the code was in IO, although that wasn't necessary. And, to be honest, the program felt very Stringy.

I slowly start with renaming the charmander functions to more human friendly ones, introduce a proper data type for the instructions, remove IO, show how separation of concerns leads to testability, and generally transform the imperative program into a functional one.

• Definitely the best nomination so far. – user34073 Jan 12 '17 at 23:26
• @DainIIIronfoot thank you. I wasn't sure whether I should nominate Charmander or the Pokedex. Either way, weren't there three other nominations yesterday? What happened to yours? *err, nvm. I don't have the reputation to read deleted posts yet. – Zeta Jan 13 '17 at 5:56

I'll nominate my own answer to "Tree abstraction". Before we can even get to evaluating the 4 tree classes, the first of the 2 underlying implementation classes has a number of issues that need to be addressed. Hopefully I've pointed out the need for checking all allocations, returning errors when appropriate (and not other times), and generally being more careful in the code.