Many times, source code complexity metrics are useful. Sometimes, they are misleading. I looked into one React component that had a McCabe complexity score of 103, which is very high. It had six different responsibilities, so I asked Claude Code to decompose the sub-components into a new sub-directory. It did. It worked. It was good. That is, all was good except for one of the new sub-components, which was still high at 79. Even so, consider how McCabe cyclomatic complexity metrics were calculated in this case: a. 12 async functions with try-catch blocks (each adds +2-3 complexity points) b. Nested conditionals in session management logic c. Multiple state transitions in non-use-case flows d. Event listener setup/teardown with conditional logic e. Timer management with multiple cleanup paths f. Lines of code I reviewed that component and questioned the value of the metrics. The source was no more complex than it was required to be. It simply had a greater number of lines than most (f: 491 LoC), but the functions were relatively small. One major strike against those functions was exception handling (a). Yet, the exception handling isn't complex. I asked Claude Code for its opinion on decomposing that component further, and it recommended not to. In fact, to do so would have made the one child components much more complex in exchange for more files, each with lower line counts. The problem? The change would introduce several hooks and move some non-business-logic into the wrong place at lower levels; again, it is not business logic. Hey, just follow all the breadcrumbs in multiple directions. Uh, no thanks. That doesn't mean that cyclomatic complexity metrics are useless. Overall, they are very helpful. Just don't be misled by a non-thinking software tool that is locked into an algorithm. Does that sound familiar? 😅