I first saw this in the Linux kernel style guide back in the 90s. The idea was that you should be able to read a function without scrolling. So that meant it would fit on screen in a standard terminal. It's a bit extreme for practical use, but the concept is important to keep in mind.
I was helping a Jr programmers with a code review a few months back. He'd been told that a particular chunk of code was "unclear", with specific emphasis on 4-line bit of logic in a 30-ish line function. He had no idea how he could make the code "more clear". It did what it did; the logic was a bit complex but the code was exact and correct.
The solution: factor out the 4 lines of code into a function. It was only ever called from that one place, but by making it a function you give the code a name, with clear inputs and outputs. Nothing changed about what the code did, but it became a lot easier to reason about.
It's a helpful lesson that generally doesn't really sink in for the first few years.
I'm also conflicted about this. Did those 4 lines of code correspond to something that was a natural concept in the problem domain? In that case, outlining it makes sense.
Otherwise, you're probably better served by keeping it where it is and adding an explanatory comment. There are times when code really is inherently complex, and hiding that may do more harm than good by making the code harder to read for everybody who comes later: they'll have to jump back and forth between the main code and the outlined function in order to follow what the code does.
Point is, what you did may have been the right choice in that particular case, but I find that it often isn't.
Do you think that's a good practice? I have always been conflicted.
For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable.
But sometimes it just is easier to move a bunch of crap to a function and abstract it away.
> For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable.
Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue.
That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does.
Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.
I’d bet that the compilers mostly commonly used would probably inline a function only used once. If not, many languages provide an `inline` keyword to tell the compiler to in-line the function directly.
Even if there was no way to inline a function, I tend to prefer code that is easy to understand over code that manages to shave off a few extra instructions. Code that is hard to understand will be hard to maintain and can lead to bugs in the future.
I was helping a Jr programmers with a code review a few months back. He'd been told that a particular chunk of code was "unclear", with specific emphasis on 4-line bit of logic in a 30-ish line function. He had no idea how he could make the code "more clear". It did what it did; the logic was a bit complex but the code was exact and correct.
The solution: factor out the 4 lines of code into a function. It was only ever called from that one place, but by making it a function you give the code a name, with clear inputs and outputs. Nothing changed about what the code did, but it became a lot easier to reason about.
It's a helpful lesson that generally doesn't really sink in for the first few years.