My rationale for adopting modified cyclomatic complexity vs the classic one is that switch statements are often appropriate constructs for patterns such as action matching (think redux), route matching, message matching, and code maintainers may not want to move away from them. Example:

switch (action.type) {
    case 'todos/todoAdded': 
      // ...
      break
    case 'todos/todoToggled': 
      // ...
      break

   // more cases...

    default:
      return state
  }

Of course it is possible to replace the above construct with something else (a map of action handlers, a builder pattern, or using some macros/decorators/metaprogramming) but that may not always be preferred.

👍 This seems like a nice addition to the complexity rule. We should put it behind an option so people can opt-in to the new behavior while keeping the default behavior the same.

@eslint/eslint-team do others agree?

If a switch statement is used without break statements, cases will fall through to the next case. For example:

function a(x) {
    switch (x) {
        case 1:
            // no break
        case 2:
            // no break
        case 3:
            // no break
        default:
            4;
    }
}

In this case, if x is 1, it will fall through all cases and eventually execute the default case. Treating this switch statement as having a cyclomatic complexity of 1 might not capture the additional complexity introduced by the fall-through behaviour right? 🤔

@amareshsm the fall through behavior isn't part of the calculation of complexity. You might be confusing complexity with code paths.

Right. Breaks in the switch statement do not affect the rule in its current version either.

Here's the PR: #18896

We have never accepted options for this rule since it is intended to work per the definition of cyclomatic complexity, and the advice was always to create a custom rule for any variations or other metrics. For example, this was the same request for switch statements: #15001

Custom rule is a fine path, especially if you want something truly custom (e.g. define your own team-specific complexity rules that don't fit any of the standard models). But Modified Complexity is a pretty common metric that a number of other code analysis tools implement consistently (I provided the references in the description), so I would consider it "standard" at this point. I could make a separate rule for it, but given how small the implementation changes are with the classic complexity metric, I think it's more practical to implement it as an option to the existing rule instead. What do you think @mdjermanovic?

@mdjermanovic I think the difference between this request and #15001 is that the latter was represented as a personal preference, and we didn't want to allow people to start arbitrarily changing how complexity was calculated. This request notes that there is a known alternative called "modified cyclomatic complexity" that changes how switch is calculated, so this is actually an option to cyclomatic complexity in the real world. That's why I think it makes sense to add as an option.