-
-
Notifications
You must be signed in to change notification settings - Fork 773
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NestedScopeFunctions - Add rule for nested scope functions #4788
Conversation
f5cdb11
to
3be97d1
Compare
...plexity/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/NestedScopeFunctions.kt
Show resolved
Hide resolved
* | ||
* [Reference](https://kotlinlang.org/docs/scope-functions.html) | ||
*/ | ||
class NestedScopeFunctions(config: Config = Config.empty) : Rule(config) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to hear what @BraisGabin and others are thinking about this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a better name in mind right now. I'm fine with the current one.
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
3be97d1
to
995a48d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
functions: | ||
- 'apply' | ||
- 'run' | ||
- 'with' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add also
and let
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, not sure. I think they are less problematic, since you can rename it
. I think they maybe better fit to NestedBlockDepth
or CognitiveComplexity
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Yeah, makes sense. Will add. |
...plexity/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/NestedScopeFunctions.kt
Show resolved
Hide resolved
...plexity/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/complexity/NestedScopeFunctions.kt
Outdated
Show resolved
Hide resolved
2704fbe
to
d5368cb
Compare
499ef41
to
1acbf18
Compare
@cortinico do you agree with merging this PR? Do you have further comments for your approval? Otherwise, I'd say LGTM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge it 👍
Fixes #4780