Back in the day when I used to practise KungFu, the start of to every training session consisted of a series of ten very simple exercises. These were “just” hand movements[1]. Compared to all the other fancy stuff we did, the big sweeping movements and the animal imitations, it seemed like nothing. A warm-up exercise at best, a nuisance at worst.
But when someone asked the Taiwanese grandmaster one day what to practise when time is very limited and you can only do one thing, even for long periods of your time, guess what he answered? Right.
Also, back when I was a student, when I first learned about all the cool programming books available on Amazon, I was deeply impressed - and this should not be taken here just as a figure of speech - by what I would sometimes call “American pragmatism.” By that I meant that they read so goal-orientied and non-nonsensical compared to all the philosophical treatises and and academic papers I was reading at the time.
A subset of these books was dedicated to describing best practises in writing code. One of the most famous books of that type was Clean Code, written by Robert C. Martin[2] and published in 2008. A earlier example is Code Complete by Steve McConnell from 1993. The starting point was usually decision making regarding low-level code constructs. How to name variables, how to name functions, when to write sub-functions, and so on. These books were decidedly language-agnostic.
One of the simplest techniques for writing better code described was to extract a new function by isolating a few lines - that belong together thematically - from an existing function, and giving it a name that describes exactly what the theme is that makes them belong together. This has the advantage that if you need to get back to any one of those lines of code to make changes, you would do that either in the mental context of the higher level or in the mental context of the lower level function, but not both at the same time. This reduces the cognitive load on the Future Developer™[3] who then won’t have to visually filter out too many lines of code irrelevant to the problem at hand, and is therefore very nice of you!
Another advantage is that the extracted functioncs are already ready to be moved around between modules. No upfront refactoring necessary. Which brings me to — refactoring. It’s most closely associated with Martin Fowler, as he wrote Refactoring: Improving the Design of Existing Code (first published in 1999). Refactoring describes concrete techniques for changing the low-level structure of code without changing its composite behaviour (the goal of these exercises is neatly described in the book’s title).
One of the most basic refactoring techniques was, again, that of extracting a function[4] from parts of another existing function. Only now had this been given a name, “extract function,” and was included in a vocabulary[5] of other refactorings.
The point I’m trying to make here is that “extract function” is basically one of the ten basic techniques of programming, in the spirit of the opening anecdote. It is literally THE EASIEST thing you can do to improve your code. It’s almost a purely mechanical thing. Most of the time it is obvious which lines of code belong in a different function. The tiny artistic touch comes into play in naming that new function appropriately, which takes a little practise to get good at. It also requires very little mental capacity and at the same time carries a very low risk of breaking something when refactoring, even if the test coverage is zero.
During my professional career I have seen a lot of code in the wild and to this day I am amazed that this is not standard practise. The explanation why this is the case is pretty simple, though. On the one hand, the topic of best practises is just one of countless other things a developer can learn. There are new languages, new versions with new features of your own language, current topics like microservices or artificial intelligence or whatever, other topics such as architecture, design patterns, career advice, time-management, note-taking techniques, etc. The list is endless. On the other hand, extracting functions seems soooo tiny and irrelevant. You can’t even impress a colleague in the way you might be able to if you can replace this or that line of code with a slightly more idiomatic or efficient code-construct.
As I said, extracting functions just does not seem fancy in any way. It’s the same as in my anecdote. The beginner always looks enviously at the big and fancy things. He is impatient to to get ahead. The other side of the coin is a neglect of fundamentals. It took the grandmaster’s answer to remind us of the immense value of basic techniques.
I believe it is the same with small functions. A code base that consists of small functions is the basis for everything else that is supposed to happen in it. Since I am by no means a grandmaster of programming, I fear my word alone will hardly convince anyone. Instead I hope - if you’re not already on board - to have inspired some of you to look up one of the original sources. For me, it was one of those things that once you’ve seen it, you can’t unsee it. I think it will be the same for you.
Thanks for reading, cheers!
Footnotes
Accompanied by minute adjustments of your hip and feet positions.
An industry veteran otherwise known as “Uncle Bob”.
Which we all know could be you ;)