Refactor for readability, not for keystrokes

Chris
Taskworld Tech
Published in
3 min readAug 26, 2017

“Optimize code for reading, not for typing.”

I have face a lot of programmer, who when refactoring, tends to optimize for number of typing strokes, at the cost of understandability

When we talk about reduce code duplication, we not try to optimized key stroke. The main concept is to centralized the domain knowledge and make changes easier.

I will give you an example where refactor based on optimizing keystroke can be harmful.

Class MyComponent extends React.Component {
render () {
//....
}
}

We could refactor to:

function createReactComponentRender (renderFunc) {
return Class ThisComponent extends React.Component {
render = renderFunc
}
}

and we can reduce both number of line and number of characters tremendously.

Fully-React version for 3 components:

Class Component1 extends React.Component {
render () {
//....
}
}
Class Component2 extends React.Component {
render () {
//....
}
}
Class Component3 extends React.Component {
render () {
//....
}
}

Refactored-React version for 3 components:

const Component1 = createReactComponentRender(() => { ... } )
const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

Wow!!! new version look lot shorter. It should be says cleaner and more precise right?

I don’t agree at all.

I would considered Fully-React version to be better code than new version.

Readability:

In term of readability, I would say any React developer can understand code in Fully-React, just by looking at the code. It simple, it is the one that you exactly see on tutorial.

While in Refactor-React version, one would have to look at definition of createReactComponentRender first to be sure what does it do.

Maintainability:

In term of maintainability, which I perceived as “how easy to make changes in code”

In this case, most obvious possible changes is to add some lifecycle method to some of components.

So what changes needs to be made in this case?

Fully-React

Class Component1 extends React.Component
shouldComponentUpdate () {
} render () {
//....
}
}
Class Component2 extends React.Component {
render () {
//....
}
}
Class Component3 extends React.Component {
render () {
//....
}
}

Refactored-React

Option 1:

Class Component1 extends React.Component
shouldComponentUpdate () {
} render () {
//....
}
}

const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

In this option, the code that needs to be changes become 6 lines, which I would say this become little bit harder to changes than Fully-React version.

Option 2:

function createReactComponentRenderAndShouldUpdate (renderFunc, shouldComponentUpdateFunc = null) {
return Class ThisComponent extends React.Component {
shouldComponentUpdate = shouldComponentUpdateFunc
render = renderFunc
}
}
const Component1 = createReactComponentRender(() => { ... }, () => { ... } )
const Component2 = createReactComponentRender(() => { ... } )
const Component3 = createReactComponentRender(() => { ... } )

This option need exactly 3 lines changes, which is same number of line as Fully-React version.

But I would say now we bloat createReactComponentRenderAndShouldUpdate , and we reduce readability by great magnitude.

This is why I think that Fully-React version is the best one, even if it takes more lines and keystrokes to write than Refactor-React one

(Actually, we can just snippet)

Moral

  1. Refactor code for shortest one, for less typing keystrokes one, can hurt maintainability and readability of the code
  2. Sometimes, duplications of big chunk of code is better handle by snippet rather than refactor to function or even meta-programming.
  3. When Refactor, try to be less biased toward keystrokes. I know that when we as a programmer, have to type same long boilerplate all the time. we tends to think of refactor and reduce the typing workload. No, we do not refactor for that. We refactor code for readability and maintainability over ease of typing. (Hint: Typing workload can be reduce greatly by just a simple snippet and scaffolding)

--

--

Chris
Taskworld Tech

I am a product builder who specializes in programming. Strongly believe in humanist.