Code complete speaks about subroutines if I understood correctly. I think that in functions, or even objects, the results would be very different. I usually find the shortest functions more powerful and clear. For example the pipe operator in F# that is nothing more than:

    let (|>) f g = g f

While it has huge benefits in the overall readability of the language.

At the end of the day, a simple measure like LOC can never capture readability, good or bad, and you get eaten by Goodhart's Law if you focus too much on it.

https://en.wikipedia.org/wiki/Goodhart%27s_law

No one would argue otherwise. Indeed, you can trivially take any readable function and transform it into an unreadable one of exactly the same length. But this doesn't seem like a valid reason to dismiss specific findings of specific studies. Don't you think it's interesting that such research as we have contradicts the most often-repeated claim about this aspect of programming?

I don't know. I've learned over the years that there is always a study confirming or contradicting whatever point you want to make. "Beware The Man Of One Study".

I say that without even looking at those studies, which is perhaps unfair. But there are So Many Studies...

My personal experience is that when I was exposed to shorter simple and (so important!) well named functions, my work became so much better. And that is now the school I subscribe to.

That's not - at all - to say you can't also find very good practices doing different things. But that's not where I found it.

Still, one study is still an important piece of evidence to consider when all you had before is no studies and a gut feeling.

My personal experience differs from yours somewhat. I believe it's not the length or the number of methods that matter, but what language (i.e. abstraction) they create. You try to subdivide the function into functions that are natural fit for the task being done, but no further. If you still end up with a long block of code - as you very well might - consider comments instead. A comment telling what the next block of code will do is kind of like inlined function, except you don't have to jump around in file, you don't lose the context. Much easier to read.

I used to write code where essentially every piece of code longer than 3-5 lines got broken out into its own private function. The amount of jumping I had to do when reading the code, and the amount of work maintaining and de-duplicating small private functions, was overwhelming.

We may not be that different.

When I was shown that you can break out a function that's only used once, just in order to name it (2005, or so), it was one of the greatest revelations in my career.

It also serves as a way to tell you what that code does, without you having to know details of how it does it, until the rare day when it's important.

But I only do it when that code is genuinely hard to follow, not because my function is "over 10 lines, and that's our policy".

agumonkey's mention of cyclomatic complexity in a parallel comment made me remember yet another realization wrt. breaking functions out: if you work with languages without local functions and start breaking your large function into smaller functions or private methods, you run into a readability/maintenance problem. The next time you open the file and start reading through all the little helper functions, you start wondering - who uses which one? How many places use any one of them?

With IDE support answering the question for a single function is just a matter of a key combination, but that still adds friction when reading. I found that friction particularly annoying, and a file with lots of small helper functions tend to be overwhelming for me to read (it's one reason I like languages with local functions). Whereas if you didn't break the code out, and only maybe jotted a comment inline, you can look at it and know it's used only in this one place.

Sure, there are both costs and benefits to this, which is why you should only do it when the benefits clearly are bigger than the costs.

Not every time your function line count is > 10, as I heard from some crazy company a friend worked for...

I prefer to put the broken out function(s) immediately below the main one for a logical reading experience: Overview first, details below if needed.

Comments are of course good when they are current and correct. But they rarely stay that way for long...

is anybody still counting states ? or use https://en.wikipedia.org/wiki/Cyclomatic_complexity ?

Oh, save us from the scenes,

Where the end becomes the means,

And the forest gets so lost among the trees;

When polishing the source,

Blunts all our creative force,

And procedure kills the genius it claims it frees.