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.
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.
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.
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 you need a whole program laid out consecutive for you to understand it, that's not great.