Lesson -1: Misconceptions

Learning about refactoring is the first step to learning refactoring. It is as important to know what refactoring is as it is to know what refactoring isn't.

This lesson goes over the standard misconceptions about the goals of refactoring.

Refactoring doesn't mean shortening code

In fact, refactored code is often larger than it's unreadable, un

, un counterpart.

Take this program for example. It reads in a chess board from standard input and prints out the material (an estimate score based on pieces in play).

When you're editing a paper, you may aim to make the wordcount increase, but end up making the essay shorter. Same with refactoring, but the other way around, the code happens to get larger. You can successfully edit an essay and get a larger or smaller essay, and the same is true with refactoring code. As long as the code improves, it's refactoring.

Refactoring doesn't mean making the code faster

In fact, refactored code is often slower than it's unreadable, unmaintainable, unextensible counterpart.

As you may have learned in other main line computer science classes, an easy way to make code faster is by converting recursion into a basic loop. This can have some benefits over

, like not accidentally copying memory after every loop. However, when it comes to the sheer readability of recursion, it is hard to justify the speed of a for loop.

Normally with these

fixes, there are ways to match the fastest code while still having the most readable code.

For example, to avoid copying memory during recursion, you can use const references or pointers.

Perhaps making a function for that chessboard example is a tad bit slower than not having to call a function. We could include the inline keyword to tell the compiler to copy and paste that code back where it was, as if we never made the function to begin with.

Usually, the compiler is smart enough to know where it is ok to make these changes for you. This is true with a ton of other things. If you think you're clever replacing i++ with ++i to save a couple of instructions, just know that the compiler probably already did that, and probably also optimized out the for loop you're working on, opting to run the whole program during compile time and store the results in the executable.

Moral of the story, optimization is normally a waste of time unless you can do something to the algorithm to change its

. That, a compiler typically won't do.

Then what's the point?

The short definition of refactoring is making code better without changing the program. The argument comes from what better means.

Code being better than other code implies that there's a value we can compare samples of code with, which is the imaginary judges score your boss gives you after you make a pull request.

While we'd like to think that our boss values short fast one-liner pieces of art...

Really, companies want it so that if you die, they can continue to maintain your code. They also want people to build off of your code, like using the same backend you wrote for a website for, say, a phone app.

So while refactoring does include optimization, it takes backseat to more organized, readable, and maintainable code.