It shouldn't be a hard rule, but in most cases a sufficiently long function will have opportunities for pulling out functions with sensible signatures that make sense outside that context.
All a linter does automatically is require adding the "ignore this line" comments that are then visible to humans in diffs.
A linter directive also tells humans that somebody has decided that the function being long is acceptable in this specific location. It's been acknowledged. In many cases, that's all I want.
Then you go from pre-linter arguments about line/function/class length to arguments over whether itβs appropriate to override the linter rule in those same instances.
> in most cases a sufficiently long function will have opportunities for pulling out functions with sensible signatures that make sense outside that context.
And will make understanding the function a lot more difficult.
If you want an example of this, look at any C++ code that uses DX12 or Vulkan. It will be atomized sufficiently that you'll have to hunt through dozens of files to figure out which constructor/destructor where something fired. Part of the problem is that C++ discourages naked functions operating on structs rather than member functions on classes.
Whereas, if those functions were still all linear in a single function, you'd find what you were looking for in the same file you were already in.
That having been said, I'll probably organize that big function as though it were separate functions. But, then, I'm not allergic to adding an extra block level here or there which GASP might exceed 80 columns.
All a linter does automatically is require adding the "ignore this line" comments that are then visible to humans in diffs.