I got into this exact argument a while ago.

We have an informal, internal audit of our code base to highlight problem areas, trends, and note if something we're doing is problematic over time. Someone suggested a hard cap of 30 lines per function.

I immediately had a rebuttal with code. We have some functions that are mostly mappers. Ingest code from one place, transform/cast/sanitize/clean it, then send it elsewhere. The types of information for some of these functions can make some of these behemoths 200+ lines. I asked my peer if they would rather follow the trail back-and-forth of 20+ helper functions or look at one monolith knowing that it only maps data?

They wanted helper functions.

To counter, I highlighted a mistake that I made years ago. I traced the revision of a file where a function mapped data that used helper functions. I pointed out that I did the exact thing suggested. There were many helper functions of 3-10 lines mapping data and returning back to a single place in a file.

I'm not that smart. Rather, I've done a lot of academic, clever, and sometimes outright dumb things, I haven't forgotten those lessons learned.

Agreed. Factoring out code to functions when those functions aren't used anywhere else to me just seems like adding an additional level of indirection that makes understanding the code more complicated, because now you have to jump between the purely declarative names and the code when in fact you're trying to follow control flow.

It's all about balance really and this is part of the problem.

1500 lines of code for a function/method would strongly suggest a problem. In the same way as a 200 function/methods would make it hard to follow.

If breaking up a procedure results in the creation of a bunch of smaller procedures that are only called once then I think I'd prefer to leave it as it was with well demarcated and commented sub-sections.

It saves you the job of inventing descriptive procedure names as well as jumping between procedures.

I seem to recall also that in Code Complete, Steve McConnell claimed that there was an inverse relation between the length of a procedure and the number of errors per line of code.

How is an inline function different from a demarcated and commented subsection? It seems to me that the semantic and enforced correctness benefits of functions would make using them in this way a no brainer.

This exactly when you break up a logically flat function into subfunctions, the names of those functions are simply replacing comments.

Sounds like it alright but I've never used one as they aren't available in the language I mostly use.

Diving into and out of functions can make the code harder to debug at first, and it can slow down how long it takes to figure out exactly what the code is doing on a micro level.

On the other hand, it greatly simplifies the process the process of understanding what a function is doing at a high level. It also makes it much easier to navigate the code quickly and determine exactly where changes need to occur.

If it's more difficult, then the small functions and classes can be improved. Alternatively, maybe you need to brush up on how you read code.

If you need a whole program laid out consecutive for you to understand it, that's not great.