Remove custom assertions that check kdoc of rules#3859
Remove custom assertions that check kdoc of rules#3859picklebento merged 4 commits intodetekt:mainfrom
Conversation
| for (ymlOption in filter) { | ||
| val configField = configFields.singleOrNull { ymlOption.key == it.get(null) } | ||
| if (configField == null) { | ||
| fail<String>("${ymlOption.key} option for ${ruleClass.simpleName} rule is not correctly defined") | ||
| } |
There was a problem hiding this comment.
This piece code is providing certain coverage for at least the rule config key "active".
There was a problem hiding this comment.
I disagree. This code explicitly ignores the active key as it is part of allowedOptions (see below).
val configFields = ruleClass.declaredFields.filter { isPublicStaticFinal(it) && it.name != "Companion" }
var filter = ymlOptions.filterKeys { it !in allowedOptions }
// ...
for (ymlOption in filter) {
// ...
}What this code acutally does is make sure there is a constant with the name of every config key (except for "active", "excludes", ...) such as.
const val THRESHOLD = "threshold"
const val FUNCTION_THRESHOLD = "functionThreshold"
const val CONSTRUCTOR_THRESHOLD = "constructorThreshold"
const val IGNORE_DEFAULT_PARAMETERS = "ignoreDefaultParameters"
const val IGNORE_DATA_CLASSES = "ignoreDataClasses"
const val IGNORE_ANNOTATED = "ignoreAnnotated"for
LongParameterList:
active: true
functionThreshold: 6
constructorThreshold: 7
ignoreDefaultParameters: false
ignoreDataClasses: true
ignoreAnnotated: []There was a problem hiding this comment.
Thanks for pointing out the logic, I did run the test in IDE again for the existing code, it looks like most of the rules are hitting the return branch of if (ruleClass.isConfiguredWithAnnotations()) return, and what I have observed is that when hitting for (ymlOption in filter), the filter is almost always an empty list.
There was a problem hiding this comment.
Yes, as all rules have been moved to the configuration by annotation that was pretty much what I expected. Is there any check you would like me to add here?
In a separate PR I was thinking about adding something to the ConfigurationCollector that fails when there is a @configuration kdoc on a rule. Technically this could be done here as well.
There was a problem hiding this comment.
Let's do it in a separate PR. Since the tests are not covering much as of today.
This is part of the #3670 cleanup.