Github, generate report for CyclomaticComplexity/all-examples-in-one

Report for CyclomaticComplexity/all-examples-in-one:
https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/f65de102b0555c70c28d26cb39a7c109094ceb01_2025085332/reports/diff/index.html

@nrmancuso @mahfouz72 please take a look at case
how should nested switch statements be treated ?

how should nested switch statements be treated

@mohitsatr please propose a couple of solutions with examples, and provide your recommendation.

Github, generate report for CyclomaticComplexity/all-examples-in-one

Report for CyclomaticComplexity/all-examples-in-one:
https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/426336353669f7dfdbe6366f33a6c98d790114e7_2025044241/reports/diff/index.html

@nrmancuso Well, according to me there are only two possible solutions:

1. Treat the outer most switch block as single decision point and ignore everything inside it, including any nested switches.
2. Treat the outer most switch block as single decision point but still count any nested switch while ignoring everything else in the block.

i went with second approach (for no particular reason).

Second Approach:
if there's a nested switch block, complexity increases for the switch keyword but anything inside that 2nd level switch block is ignored. in other words, complexity is just no. of switch keywords in the function.
See the example below :

// Cyclomatic Complexity is 4 
void test3(Object obj1, Object obj2, Object obj3) {
        int j,k,l,m;
        switch (obj1) {                //1
            case Integer i1:
            case Integer i2:
            case Integer i3:
                break;
            case Integer i4:
                switch (obj2) {        //2
                    case Integer i1:
                       j = 1;
                       break;
                    default:
                        break;
                }
                break;
            case Integer i5:
                if (j == 1) {               //ignored
                    k = 1;
                }
                else {
                    l == 1;
                }
                break;
            case Integer i6:
                switch (obj3) {        //3
                    case Integer i6:
                        break;
                    default:
                        break;
                }
                break;
            default:
                break;
        }
    }

but that raises the question: why not the first approach ? why are we even worrying about switch block inside a switch block. we can simply ignore everything inside the switch block. After all switchBlockAsSingleDecisionPoint is not the default behaviour and if a user enables it, then they must expect Check to ignore nested switches too, right ?

I vote for (1), @mahfouz72 @romani @rnveach what do you think?

@mohitsatr , please proceed with (1). This is the only possible way, switchBlockAsSingleDecisionPoint is driving behavior, no need to look inside switch at all.

Github, generate report for CyclomaticComplexity/all-examples-in-one

Report for CyclomaticComplexity/all-examples-in-one:
https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/6c6c0ee42754469c64961c47273462e52101f030_2025040344/reports/diff/index.html

@mohitsatr , please check jdk21 compilation .

Remove wip from description.

@romani have you gone through the regression report ? don't want to waste time if it's already reviewed by you.

@mohitsatr , I am waiting explicit comment that PR is ready for review as it was in WIP for long, so please do all verifications on your side first.

@romani this one is ready for review. on my part I checked all the files in report and Im pretty confident that change is working . I have not gone all in Openjdk. it is tiring.

Github, generate report for CyclomaticComplexity/all-examples-in-one

Report for CyclomaticComplexity/all-examples-in-one:
https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/e4c1522c54b4405dd0b9fc03236948b914810eca_2025040235/reports/diff/index.html