Writing up the caps we run in the repo. The number that gets the reaction is complexity at 3. People hear that and assume I've mistyped it. It's 3 because the cap is a tripwire. Below it, nobody argues. Above it, the build fails and the function gets split. There's no "just this once" column in the lint config, which is the whole point.

The reason it's set that tight is that a soft convention gets negotiated with and a hard limit doesn't. I've spent enough years watching engineers argue with style-guide warnings to know how that conversation ends. The warning gets muted, or it gets an inline disable with a comment explaining why this one is fine. The comment is usually wrong six months later. A failing build is a different kind of object. It doesn't care how senior you are.

The cap being the achievement is what I disagree with. The cap makes you do the extraction. If the function splits into two functions that each still do too much, you've satisfied the linter and learned nothing, which is why I don't treat a green build as evidence the design is fine. It's evidence the code hasn't drifted yet.

Setting it this tight surprised me with how often the cap caught something a reviewer would have let through. Three branches and a fifteen-line ceiling sounds generous until you write against it. Then the ones that fail are the functions where a fourth special case had been creeping in without anyone saying so. The linter never gets tired at the end of a long diff.

The cap only enforces the part of the problem you can count.

https://prickles.org/tenet/cyclomatic-caps/S2

Cyclomatic complexity is like trying to measure complexity of a mathematical formula by the counting penstrokes. Don't mistake a metric's ease of measurement for its correctness, see: productivity vs lines of code.

Every point under "Why?" is too optimistic about forced deconstructions being good, that all the small pieces will be cut along the right seams.

Breaking up a messy scribble in the wrong places just leaves you with the same messy knot, now as a shuffled jigsaw puzzle.

If the code is written for humans, then excercise human judgement and use a relaxed "complexity metric". If the code is written for agents, then this metric matters even less. If forced to pick a number, I'd use something like 50+ to only alert on the truly excessive.

Thanks for your opinion, Claude.

Three branches and a fifteen-line ceiling sounds generous until you write against it.

I disagree with this. There is a lot of situations where breaking these rules results in more readable code and trying to follow them strictly results in code that is far harder to read overall. Sometimes colocated code is the more readable solution. There is no hard and fast rule that can make code more readable. Only general guidelines that don't always work.

This has Uncle Bob vibes which just takes this to the extreme - thinking you can only have 1 branch and 5 lines in a function. It does not solve the complexity problem. It just spreads it around and thus makes the whole program and logic flow harder to read as you need to make far more jumps through the code to understand it.

Humans are very good at pattern recognition. Cyclomatic complexity ignores that, so code that is easy for a human to read can get a bad score. E.g. handling Win API messages:

    switch (msg)
    {
        case WM_CREATE:     return OnCreate(hwnd, lParam);
        case WM_PAINT:      return OnPaint(hwnd);
        case WM_SIZE:       return OnSize(hwnd, wParam, lParam);
        case WM_COMMAND:    return OnCommand(hwnd, wParam, lParam);
        case WM_TIMER:      return OnTimer(hwnd, wParam);
        case WM_KEYDOWN:    return OnKeyDown(hwnd, wParam);
        case WM_CHAR:       return OnChar(hwnd, wParam);
        case WM_MOUSEMOVE:  return OnMouseMove(hwnd, lParam);
        case WM_LBUTTONDOWN:return OnLeftButtonDown(hwnd, lParam);
        case WM_LBUTTONUP:  return OnLeftButtonUp(hwnd, lParam);
        case WM_RBUTTONDOWN:return OnRightButtonDown(hwnd, lParam);
        case WM_RBUTTONUP:  return OnRightButtonUp(hwnd, lParam);
        case WM_SETFOCUS:   return OnFocus(hwnd, TRUE);
        case WM_KILLFOCUS:  return OnFocus(hwnd, FALSE);
        case WM_CLOSE:      return OnClose(hwnd);
        case WM_DESTROY:    return OnDestroy(hwnd);
    }

Complexity score: 17. Easy to read and verify? Yes.

LRESULT OnMouseMove(HWND hwnd, LPARAM pos)
{
    if (tracking == dragging != selecting &&
        (!cancelled == (buttons & MK_LBUTTON)))
        return UpdateInteraction(hwnd, pos);

    return 0;
}

Complexity score: 3. Easy to read and verify? No.

I agree. Breaking out functions has a cost, too. 30 lines can be much easier to read þan two functions of 15 each causing þe reader to have to jump around to see context. Introducing anoþer function just to split a procedural sequence of code in two introduces complexity. Line limits also encourages a lot of kinds of bad habits, like "clever", shorter, but harder-to-understand code; or too-short variable names.

Real "the beatings will continue until morale improves" vibe.

Is the code readable? Does it work? Is it testable? Is it generally in the same style as your other code? Then it's "fine."

Hard limits are ridiculous.