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
Bug 1805070 - Update detekt to v1.22.0 in A-C #292
Bug 1805070 - Update detekt to v1.22.0 in A-C #292
Conversation
c4db5af
to
cb00b2a
Compare
84addcc
to
aeab1bb
Compare
@@ -32,7 +39,15 @@ console-reports: | |||
# - 'NotificationReport' | |||
# - 'FindingsReport' | |||
# - 'FileBasedFindingsReport' | |||
- 'LiteFindingsReport' | |||
# - 'LiteFindingsReport' |
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.
Uncommented this since there's no reason to really exclude this or any particular reports.
LibraryCodeMustSpecifyReturnType: | ||
active: true | ||
excludes: ['**'] | ||
LibraryEntitiesShouldNotBePublic: |
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.
The library ruleset is now introduced via a new plugin, which I didn't import. See https://detekt.dev/changelog#migration
We can followup on this if you believe we want these library ruleset.
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.
Thanks, this looks good. The file is quite large to check every change, but maybe we can fixup the config as we go about it? I left some comments on the focus-android detekt that apply for the A-C one too.
focus-android/quality/detekt.yml
Outdated
UseCheckNotNull: | ||
active: true | ||
UseCheckOrError: | ||
active: false | ||
active: true |
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.
Why make this true? I see that the detekt team are enabling them default true as a way to promote, but I don't see the value it brings. Do you have a stronger opinion to wanting this updated?
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.
See #292 (comment)
UseAnyOrNoneInsteadOfFind: | ||
active: false | ||
active: true | ||
UseArrayLiteralsInAnnotations: |
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.
Same for this one, the docs say it's more readable but I don't see any reason to make us change our default.
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.
This is enabled by default in detekt since v1.21.0 https://detekt.dev/docs/rules/style/#useanyornoneinsteadoffind. I wouldn't say we really have our own default except where we have a comment that stated that we enabled or changed a property and the PR/issue that was responsible for that decision. Our default is more based on what was the default of the previous base configs.
I would lean towards following the base configuration because keeping this inactive means we have an intentional intervention and now requires another comment about why or when we made this decision. Looking at the code sample, I don't see any reason why we wouldn't want to accept more readable code.
I am also thinking about this from an upgrade point of view where we are currently diff our current config and the new base config to sync any new rules that needs to be added to the file. After this upgrade, I am looking to remove most of the default configurations in favour of using buildUponDefaultConfig.
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 am also looking to turn on more rules after this. Especially rules that will make our code more readable and simplifies things for us. Based on our review guidelines, I want to front load and really empower our linters to do most of the heavy lifting by being more opinionated because most of my review codes are based around simplifying and making code more readable.
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.
This is enabled by default in detekt since v1.21.0 https://detekt.dev/docs/rules/style/#useanyornoneinsteadoffind.
I was referring to the line I commented on, UseArrayLiteralsInAnnotations
. Using any
or none
sounds fine to me.
Our default is more based on what was the default of the previous base configs.
This is not true. We chose our defaults intentionally based on our needs.
Looking at the code sample, I don't see any reason why we wouldn't want to accept more readable code.
I am all for this, but using defaults aren't adding that value, it is just code churn. UndocumentedPublicClass
, UnreachableCatchBlock
and CognitiveComplexMethod
are valuable to the code base. The detekt defaults are made by the developers that want to switch some changes to true because they invested in building those but that does not mean those make sense for us.
making code more readable.
Great! Some of these checks are not readable to me though (and maybe others). 😅
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.
@jonalmeida @gabrielluong I've looked through the rules now, and thought about your discussion:
I like the adjustments of existing rules that have already been active, but recommend that we do not introduce new rules, as part of this PR. This is so the PR can be unblocked (it's been around for a while), and because I think some of these rules require more discussion e.g., InjectDispatcher
, which we already violate in various places, and just ignoring those cases isn't good either.
I recommend landing this without introducing any new rules, but with the refinements, and putting up separate PRs for specific new rules. On those PRs, we can then also include the required refactorings to actually follow the new rules. This will allow us to properly judge if we want to introduce these new rules or not.
OutdatedDocumentation: | ||
active: false | ||
matchTypeParameters: true | ||
matchDeclarationsOrder: true | ||
allowParamOnConstructorProperties: false |
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.
👍 This one is good, because I remember complaining about this in reviews a lot :)
thresholdInFiles: 26 # (Default: 11) Increased in https://github.com/mozilla-mobile/android-components/pull/9927 | ||
thresholdInClasses: 26 # (Default: 11) Increased in https://github.com/mozilla-mobile/android-components/pull/9927 | ||
thresholdInInterfaces: 26 # (Default: 11) Increased in https://github.com/mozilla-mobile/android-components/pull/9927 | ||
thresholdInObjects: 26 # (Default: 11) Increased in https://github.com/mozilla-mobile/android-components/pull/9927 | ||
thresholdInEnums: 11 | ||
ignoreDeprecated: false | ||
ignorePrivate: false |
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.
Up to here, the refinement of rules that have already been active look good to me!
aeab1bb
to
af35639
Compare
This pull request has conflicts when rebasing. Could you fix it @gabrielluong? 🙏 |
This is just waiting for me to go through the review feedback and making the changes. |
af35639
to
d1ffb5e
Compare
@jonalmeida This is ready for a review. There's no new rules that are turned on in this iteration. I added a comment next to each rule that differ from the default detekt configuration to indicate that these are turned off intentionally. That way when we need to bump the detekt version and update our config again we will hopefully not just take the defaults as is. The configs in Fenix and Focus are directly copied from the AC config. |
This pull request has conflicts when rebasing. Could you fix it @gabrielluong? 🙏 |
… the team Add a note to each rule and configuration to note their original default value and the issue or PR that modified the rule.
d1ffb5e
to
eab6005
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.
LGTM! I only reviewed the AC version on the understanding that the Fenix and Focus ones are identical.
13a0712
to
eab6005
Compare
I compared various base configs (1.22.0, 1.19.0 and our original 1.0.0RC6) to note any changes. Most of the changes will have come from the latest default base config which has turned on a lot more rules.
I also annotated rules and configurations where our team has manually checked the default settings and added a link to the original issue (if it exists) or the PR.
Pull Request checklist
After merge
GitHub Automation
https://bugzilla.mozilla.org/show_bug.cgi?id=1805070