NestedScopeFunctions - Add rule for nested scope functions

[WildOrangutan]

Fixes #4780

[cortinico]

nit: I'm not a super big fan of this rule explicitly mentioning ScopeFunctions while in reality you can customize the functions. So theoretically you could use this rule to check the nesting of your own non-scope functions.

[WildOrangutan]

Hm, dunno. Judging by this, scope is general term and not explicitly tied to "scope functions" like apply.

I'm not a Kotlin expert tough, so let me know, if you have better naming in mind. Not sure how else to name it tough. One alternative I see is NestedFunctions, but that can be confusing (function definition in a function).

[cortinico]

Happy to hear what @BraisGabin and others are thinking about this

[schalkms]

I don't have a better name in mind right now. I'm fine with the current one.

[codecov]

Codecov Report

Merging #4788 (1acbf18) into main (22bc63d) will increase coverage by 0.02%.
The diff coverage is 90.19%.

@@             Coverage Diff              @@
##               main    #4788      +/-   ##
============================================
+ Coverage     84.70%   84.73%   +0.02%     
- Complexity     3426     3432       +6     
============================================
  Files           491      492       +1     
  Lines         11253    11304      +51     
  Branches       2069     2077       +8     
============================================
+ Hits           9532     9578      +46     
- Misses          676      677       +1     
- Partials       1045     1049       +4     

Impacted Files	Coverage Δ
...ch/detekt/rules/complexity/NestedScopeFunctions.kt	90.00% <90.00%> (ø)
...osch/detekt/rules/complexity/ComplexityProvider.kt	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 22bc63d...1acbf18. Read the comment docs.

[BraisGabin]

First of all: Thanks for this new PR! It looks really good.

I'm wondering, should we use here the same function matchers as we use in ForbiddenMethodCall?

    private val methods: List<FunctionMatcher> by config(
        listOf(
            "kotlin.io.print",
            "kotlin.io.println",
        )
    ) { it.map(FunctionMatcher::fromFunctionSignature) }

So instead of:

    functions:
      - 'apply'
      - 'run'
      - 'with'

We write:

    functions:
      - 'kotlin.apply'
      - 'kotlin.run'
      - 'kotlin.with'

This would avoid collisions between functions with the same name.

[BraisGabin]

I would add also and let too.

[WildOrangutan]

Hm, not sure. I think they are less problematic, since you can rename it. I think they maybe better fit to NestedBlockDepth or CognitiveComplexity?

[BraisGabin]

For sure this is debatible. The good part is that this is configuratble so anyone could decide if they want to add or to remove some functions.

My 2 cents: If we add let and also and someone doesn't agree it's easy to remove. If we don't add them and someone want those too added is less likely that he/she add them. For that reason I'm thinking about adding them. But I'm ok about keeping them out. If someone else could share his/her opinion I think it would be great.

[WildOrangutan]

Maybe smth in the middle - report nesting, when multiple it (or same name) are used, since that's problematic from my pov. Maybe in a next MR, so we don't drag this one too much. I can add them for time being.

[WildOrangutan]

I'm wondering, should we use here the same function matchers as we use in ForbiddenMethodCall?

Yeah, makes sense. Will add.

[schalkms]

@cortinico do you agree with merging this PR? Do you have further comments for your approval?

Otherwise, I'd say LGTM.

[cortinico]

Let's merge it 👍