3 ms·

Personally I have a strong distaste for projects that try to use some metric for how long a function should be, e.g. line count or cyclomatic complexity. I'm no

by jchw 2y ago

Personally I have a strong distaste for projects that try to use some metric for how long a function should be, e.g. line count or cyclomatic complexity. I'm not sure if this one is better automated, human judgement for what makes sense seems better to me. Sometimes the cleanest and highest performance way to write some code is going to be basically one relatively large function. If there's a function complexity/size lint I'll often chunk off helper functions that are virtually useless outside of that specific function, and in doing so, often make it harder to follow what's going on. This isn't universally true of course, but it's a "when not if" situation if you have a hard lint limit and it's not very high. (e.g. In my opinion if you're going to have a lint for this, set it to something rather obscene, something that would be extremely hard to cross without doing something clearly awful. In my opinion it's always been set at least 4 times lower than it should be.)

Kinrany 2y ago
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.
- bryanlarsen 2y ago
  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.
  - mckn1ght 2y ago
    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.
- bsder 2y ago
  > 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.
praptak 2y ago
Linux C style guide has this summarized pretty well: "The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it’s OK to have a longer function. However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely." "Less-than-gifted first-year student" is btw a great bar for the conceptual complexity. Another one I've seen elsewhere is "An SRE not familiar with the code woken up at 3 AM to troubleshoot an outage".
- loeg 2y ago
  This is essentially a rough measure of cyclomatic complexity.
  - plorkyeran 2y ago
    Unfortunately I think that cyclomatic complexity is a rough measure of this. It’s an attempt at an objective measurement, but I’ve never found it to be a particularly good one.
- arp242 2y ago
  What really matters is "can I understand what this function roughly does at a glance?" In general, "length of function" is a reasonably-ish proxy for it, but as your quote says, sometimes longer is okay, and sometimes there are also other factors than just "length of function". Either way, the question you should be asking during review is "can I understand this function?" and not "how long is this function?"

by jchw 2y ago

Kinrany 2y ago

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.

bryanlarsen 2y ago
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.
- mckn1ght 2y ago
  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.
bsder 2y ago
> 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.

praptak 2y ago

Linux C style guide has this summarized pretty well: "The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it’s OK to have a longer function. However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely." "Less-than-gifted first-year student" is btw a great bar for the conceptual complexity. Another one I've seen elsewhere is "An SRE not familiar with the code woken up at 3 AM to troubleshoot an outage".

loeg 2y ago
This is essentially a rough measure of cyclomatic complexity.
- plorkyeran 2y ago
  Unfortunately I think that cyclomatic complexity is a rough measure of this. It’s an attempt at an objective measurement, but I’ve never found it to be a particularly good one.
arp242 2y ago
What really matters is "can I understand what this function roughly does at a glance?" In general, "length of function" is a reasonably-ish proxy for it, but as your quote says, sometimes longer is okay, and sometimes there are also other factors than just "length of function". Either way, the question you should be asking during review is "can I understand this function?" and not "how long is this function?"