Title: Code refactoring should not be done just because… Author: Andrew Nacin Published: March 23, 2011 Last modified: October 11, 2014 --- [ ](https://profiles.wordpress.org/nacin/) [Andrew Nacin](https://profiles.wordpress.org/nacin/) 5:06 pm _on_ March 23, 2011   # Code refactoring should not be done just because… Code refactoring should not be done just because we can. There are a number of “ refactoring” tickets that seem to be missing the mark. Meanwhile, plenty of tasks are far more worthy of effort. Here are some suggested guidelines on what these tickets need in order to get any review: * **Unit tests**, even if the code was not previously covered. We can’t afford regressions, and this will improve our test coverage. * **Performance benchmarks**, before and after. We can’t afford regressions. * **Proper justification and clear rationale** of changes are both necessary. Too often it is impossible to determine the purpose, objective, or focus of these patches. Code should not be rewritten under the cloaks of readability, narrow personal opinion, or general subjectiveness. When none of this is followed, the end result is that reviewers and committers are distracted, which drains important attention and focus that should be spent elsewhere. There’s a document on contributing to the Linux kernel with [a section on pitfalls](http://www.linuxfoundation.org/content/41-pitfalls) when handling coding standards. I believe this can apply to the wider picture of refactoring as well (emphasis mine): > The kernel has long had a standard coding style, described in Documentation/CodingStyle. > For much of that time, the policies described in that file were taken as being, > at most, advisory. As a result, there is a substantial amount of code in the kernel > which does not meet the coding style guidelines. The presence of that code leads > to two independent hazards for kernel developers. > **The first of these is to believe that the kernel coding standards do not matter > and are not enforced. … The other trap is to assume that code which is already > in the kernel is urgently in need of coding style fixes.** I’m going to start linking to this post in various tickets. ### Share this: * [ Threads ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=threads) * [ Mastodon ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=mastodon) * [ Bluesky ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=bluesky) * [ X ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=x) * [ Facebook ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=facebook) * [ LinkedIn ](https://make.wordpress.org/core/2011/03/23/code-refactoring/?share=linkedin) # Post navigation [← Bug gardeners there is now a 3.2 milestone…](https://make.wordpress.org/core/2011/03/21/bug-gardeners-there-is-now-a-3-2-milestone/) [The student application period opens on Monday For… →](https://make.wordpress.org/core/2011/03/24/the-student-application-period-opens-on-monday-for/)