---
title: "Comment by Chris Tanner on \"Refactoring old code\" | Hashnode"
description: "" Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality." I don't th"
url: "https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b"
---

[Discussion](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49)

Comment [Refactoring old code](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49)

[Jan 14, 2021](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b)

" 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.

[Chris Bongers](https://hashnode.com/@dailydevtips)

[Jan 14, 2021](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b#reply-60007b9ab00f7510ee95aa71)

I tend to disagree with you there Chris.

This book is specified on PHP, but the concept has some valid points.

[adamwathan.me/refactoring-to-collections](https://adamwathan.me/refactoring-to-collections/)

However: I might have better called this article: "Modernizing your code" instead of refactor

[Chris Tanner](https://hashnode.com/@kraftman)

[Jan 15, 2021](https://hashnode.com/posts/refactoring-old-code/5fffe819c162d710c9b14a49/comment/600079b6b00f7510ee95aa5b#reply-6001b22836551629d6a7e202)

[Chris Bongers](https://hashnode.com/@dailydevtips)

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)