Finding the Toasters: A Few Tips On Refactoring Code

When it comes to refactoring code, it can be helpful to find toasters inside of the code.

So what is refactoring code?

We've all done it. Refactoring code is when you take existing code and improve it. You either make it better, or more readable, or both. 

For example: you might take one hugely complicated block of code and break it down into multiple small functions (I have written about this before here). 

Or you could do something to make the code run faster and with less memory.

So what are toasters?

Toasters, inside of a codebase, are something that input something and output something.

Toasters can be obvious, for example what a function takes in, and what it returns.

However, toasters in codebases can also be less obvious.

For example, a function might read a file inside of its body and this might be an unexpected input. And by unexpected, I mean something that you might not find inside of the obvious places, and by that I mean:

• the parameters, and 
• the return statement

An unexpected output might be something that gets triggered as a result of calling a function inside of the function. 

For example, calling a function inside of another function might be an unexpected output of a function call - something gets set off and you don't even realise it unless you have read the code properly.

So toasters can be obvious, and not so obvious.

What about toasters inside of functions?

And so one of the most obvious - and useful, and helpful - places to look for toasters is inside of functions. 

What is a toaster inside of a function, you may ask? Well this might be defined as - and I quote directly from one of the greats - "one or more lines of code which take an input and produce an input (the output might be assigned to a variable)". So to put it in my own words:

A toaster inside of a function might be one or two lines of code. These one or two lines of code might take an input and produce an output. An output doesn't necessarily have to be what's returned in a function - it can be something that's saved to a variable.

I repeat - an output of a toaster that's inside of a function can just be what's saved to a variable.

And so why is seeing toasters inside of functions helpful?

I have to quote from the legend again directly - because he just put it so well himself:

"Seeing the inputs and outputs across various lines of code is very useful and helps us to read a big function as a few steps within (rather than lots of lines to think about individually)."

I love this!!! So what does this mean? It means that code can be hard to understand if we just read it line by line and think about each line indivudally.

This means that if we think about code in terms of STEPS INSIDE OF A FUNCTION, AND WE THINK ABOUT THOSE STEPS, then code suddenly becomes a lot easier to read. Btw this is a great way to think for WRITING FUNCTIONS - and SOLVING PROBLEMS - too!

More words from the Great

(as in, my great software engineering mentor)

I know I am quoting him a lot today but he is just so quotable today and just so one fire. 

"Identifying simple input(s) and output(s) helps with working out how the code can be refactored."

"Keeping the inputs and outputs as simple as possible in general is a good thing."

In general, he said that "keeping inputs and outputs as simple as possible in general is a good thing."

And finally he also said that:

"If you can spot the  different toasters in the lines of code and potential ways the toasters can be changed, then the tradeoffs can be compared between different potential solutions".

And then this leads me to the next post I hope which will be on TRADEOFFS! Part two of this, I hope, it is COMING SOON...

How soon though I do not yet know!