Hacker News Reader

Comment by eru | Hacker News Reader

As for functions, there is an explicit benefit in cutting your longer (pure!) functions into a few shorter ones if possible:

Functions communicate with the outside world only via arguments and returned values. The explicit split reassures the reader that this is indeed the case, and thus every reader doesn't have to establish this fact via careful reasoning again and again.

A long function might indeed be simple, but you never know until you check carefully.

(This only applies to pure functions. Natural language sentences and side effecting procedures are messier.)

View on HN

Have you measured this benefit in any empirical way?

It is a bit dated now, but Code Complete cites actual attempts to study the connections between function length and maintenance cost in real world code bases. The conclusion was that functions with a high internal complexity were maintenance hazards. Basically add up all of the if's, loops, and so on, and if that is a big number, then break it up. However long functions without internal complexity were not a maintenance hazard. This was true up to about 200 lines.

OK, a lot has changed since IBM studied maintenance costs in the 1980s. But the received wisdom today about short functions was already the received wisdom then. And the wisdom today is just as much based on opinion as it was then.

Is there any more reason why we should accept the received wisdom today than there was then?

Good points.

My argument was actually mostly from a Haskell point of view, and a study there would be somewhat harder to define: you are defining functions all the time: especially in imperative code (do-block / monads) each line is actually a callback.

You could go by purely syntactical criteria, though. Culturally, even a single screenful of code is considered rather long for one definition in Haskell.

another way to accomplish this goal is to write your function using only const variables. every time you'd mutate a variable, use a new const variable instead. you end up transforming the code into static-single-assignment form, which is what compilers do anyway, so you can be sure it won't degrade performance.

this style really makes you wish C/C++ had if expressions. you end up using a lot of ternary operators to compensate.

it makes the code a bit more verbose, but its worlds better than poring through a function to make sure nothing is mutated in an unexpected way.

I actually prefer ternary expressions in many situations, once you're familiar with the syntax they're more concise and more clearly an expression rather than flow control.

I reach for Haskell whenever possible to get similar effects.

> you end up transforming the code into static-single-assignment form, which is what compilers do anyway, so you can be sure it won't degrade performance.

I don't know my way around compiler internals, but this sounds a little suspect to me. It seems to me—just a tyro's opinion—that (1) work spent doing what the compiler will do anyway is probably work wasted, and (2) it is possible to get in the compiler's way even if you are trying just to do what it would do anyway, thus causing unexpected degradation.

I bet the author calls for making functions just right in size to leverage self-containment and complexity, instead of panicking after crossing some magical number of lines.

This is actually compatible with DRY, because overpartitioned functionality will require more state to be pulled from function to function, resulting in repeating, long argument lists.

More basic than that, it also forces you to physically move away from the function in order to continue reading. It would be like turning to a different page in order to read the middle part of a paragraph.

On the other hand, function calls in hot code are expensive.

Pareto Principle: don't treat all of your code as if it is "hot." It isn't.

Or the law of opposites: you can't have hot without cold. Then again, you can also judge something as cold when it's hot, for instance a big loop inside a function that gets called once, and you're only profiling at the level of function call counts.

Only if your compiler ain't smart enough.

Yes, for some compilers and interpreters performance considerations will force you to write less than readable code.

Inlining is great but it's generally finnicky and hard to control so when it comes to hot loops that matter you may as well do it by hand.

Most compilers have a way to explicitly force functions to be inlined. "Just inline it by hand" is terrible advice.

I'd be very interested to see a compiler where you can force inlining. How does it handle cycles in the call graph? How does it handle code bloat because the inline keyword was used too often?

In GCC at least, you can only give suggestions. The following options control the inliner:

max-inline-insns-single: Several parameters control the tree inliner used in gcc. This number sets the maximum number of instructions (counted in gcc's internal representation) in a single function that the tree inliner will consider for inlining. This only affects functions declared inline and methods implemented in a class declaration (C++). The default value is 300.

max-inline-insns-auto: When you use -finline-functions (included in -O3), a lot of functions that would otherwise not be considered for inlining by the compiler will be investigated. To those functions, a different (more restrictive) limit compared to functions declared inline can be applied. The default value is 300.

max-inline-insns: The tree inliner does decrease the allowable size for single functions to be inlined after we already inlined the number of instructions given here by repeated inlining. This number should be a factor of two or more larger than the single function limit. Higher numbers result in better runtime performance, but incur higher compile-time resource (CPU time, memory) requirements and result in larger binaries. Very high values are not advisable, as too large binaries may adversely affect runtime performance. The default value is 600.

max-inline-slope: After exceeding the maximum number of inlined instructions by repeated inlining, a linear function is used to decrease the allowable size for single functions. The slope of that function is the negative reciprocal of the number specified here. The default value is 32.

min-inline-insns: The repeated inlining is throttled more and more by the linear function after exceeding the limit. To avoid too much throttling, a minimum for this function is specified here to allow repeated inlining for very small functions even when a lot of repeated inlining already has been done. The default value is 130.

max-inline-insns-rtl: For languages that use the RTL inliner (this happens at a later stage than tree inlining), you can set the maximum allowable size (counted in RTL instructions) for the RTL inliner with this parameter. The default value is 600.

So, while the inliner is great, if performance really matters for a hot loop, and you definitely want that code to be inlined, you might end up having to do it by hand. Because otherwise, if you change something somewhere else in your program, the inliner might suddenly decide not to inline your function anymore. You could say the same thing about virtual functions: devirtualization is great but it's not guaranteed. Or loop unrolling. Or codegen. Or whatever.

GCC and clang have __attribute__((always_inline)). VC++ has __forceinline. All of these will always inline unless it hits a recursive call. They do not attempt to avoid code bloat from the programmer telling it to do stupid things.

Ok, I forgot about always_inline. That is a good point. Anyway, it doesn't work for polymorphic (technically non-static) or recursive code. If you've split your program up into lots of pretty little functions, which is fine, you probably have a bunch of polymorphic and recursive code. Typically you get rid of those things by inlining and/or cloning. (Recursive algorithms use the call stack as an implicit data structure, which you can get rid of by introducing an explicit stack locally.) So, to force the compiler to inline some stuff, you have to inline some other stuff. Which is also fine, just that compilers are not magic. For really important things, you need to look at the generated output and decide if you can do better.

On the third hand, premature optimisation is the root of all evil. :-) It's a lot easier to convert well chunked, modular functions into monolithic blocks than it is to go the other way around.

There was just recently an article about how there is merit to the idea that it is easier to chunk up a monolith than it is to reason about poorly done microservices. Functions, when used in excess, seem to fit the same pattern. Now... good luck getting me to define excess. :)

The HN discussion of the article (MonolithFirst) was https://news.ycombinator.com/item?id=9652893 , and it's a good point to bring up.

I think that that article describes a reaction against a too-hasty move towards microservices, and (as someone who's not a businessperson myself!) as such it seems well advised; but I suspect that there is, among programmers at large, no too-hasty move towards 'microfunctions', and so no corresponding need to urge people to make the kind of monolithic monstrosities that novice (and even sometimes experienced) programmers are all too willing to make anyway.

Reply on news.ycombinator.com