[gizmo]

Because it's an artificial constraint that makes code worse. You end up with a whole bunch of functions that have only a single call-site and half a dozen parameters that don't make much sense. If you can only understand what a function does by looking at the call site then the function is no longer a self-contained piece of functionality and it shouldn't exist.

When you write very simple code you can have short functions that do one thing. When you work on more complex projects some functions will just be 300 lines long and breaking them up will just make the code harder to understand and harder to work with.

Take sqlite for instance: https://github.com/smparkes/sqlite/blob/master/src/vdbeaux.c

You'll find plenty of cases where functions do multiple things in sequence and those functions are long-ish because of it, and some "clean code" type programmers would feel compelled to refactor the code and make it way worse.

[whstl]

"If you can only understand what a function does by looking at the call site then the function is no longer a self-contained piece of functionality"

Wow, this is a solid guideline. Alright perhaps "SOLID" isn't the best adjective to use, but it's great advice :)

I find this in line with John Ousterhout's "Philosophy of Software Design", where there's a guideline saying that modules (classes/functions/components/etc) should be deep and interfaces simple. Instead of dividing methods/classes due to their size in lines, you should be dividing where interfaces can be simpler. Because a complex interface imposes a lot of complexity in the consumers of the module.

[gizmo]

His book was pretty good, and I very much agree about the importance of good interfaces. It's the essence of computing, because file formats, data types, and protocols are just interfaces by another name.