---
title: "Chris Tanner (@kraftman) | Hashnode"
description: "Chris Tanner (@kraftman) writes on Hashnode. Read their latest articles and follow their work."
url: "https://hashnode.com/@kraftman"
---

@kraftman

# Chris Tanner

@kraftman · Joined January 2021

## Comments

[For #4 your 'break down' code is much easier than your concise reducer code. It has good comments, good variable names, etc. It's much easier to read. We aren't charged by lines of code, and the less complex code is the less chance of introducing bugs. Private variable naming also costs nothing and may prevent bugs.](https://hashnode.com/posts/how-you-should-not-write-code-or-javascript/6043adb65a56f82fa3ecbec6/comment/604645f673cc1742999bfbdc)

Comment · Article · Mar 8, 2021 · [How you should not write code | JavaScript](https://hashnode.com/posts/how-you-should-not-write-code-or-javascript/6043adb65a56f82fa3ecbec6)

[Chris Bongers Let's look at the pros and cons of this modernising. Pros: Uses modern technology, which is good, because... modern? Uses less lines of code. Cons: Readability - in an ideal world everyone would be up to date with ES6, but in reality most people are wayyy behind. I bet if you took a survey of software developers and asked them if they knew what a for each does vs Object.Entries, you'd have a lot more that understand the former. If the goal is to have clear code with a low probability that someone else modifying the code will make a mistake, going will the former will be more likely to achieve that. It's much safer to go with the lowest common denominator. Bugs - Every time you modify code, there is the potential to add new bugs to the software. You have to weigh up this risk vs the benefit of making the changes. Usually code changes are either making the code more efficient, easier to read, or adding some new feature, which trumps the risk of creating bugs. Efficiency - map is less efficient than for each, so this code will most likely be slower Time - This took some amount of time and thought to implement, and presumably test. Since the code produces the same outcome, the time could have been better spent on producing value. Debugging - It's harder to debug your script since it's so condensed. The old one you can just set a breakpoint on the line you want to debug, the new one you have to set a breakpoint on the line you want to debug, then the subsection. (Support for this has only just been added to vscode, support in other IDEs might not be there)](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b#reply-6001b22836551629d6a7e202)

Reply · Article · Jan 15, 2021 · [Refactoring old code](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49)

[" Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality." I don't think you've improved the design, structure, or implementation of this code. You've taken some clear, easy to read code, and made it harder to read. You've decreased the number of lines being used, but what's the benefit of that? We aren't charged by the number of lines we use. Please, please don't do this.](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b)

Comment · Article · Jan 14, 2021 · [Refactoring old code](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49)