Improve your code with Lint checks for Kotlin
summary
A team builds an AR SDK and makes Android Lint run on every Gradle build to break only on new errors, not historical ones, by committing a baseline snapshot and tuning a lint XML to ignore or escalate groups. Kotlin checks run once per file via UAST detectors implemented as custom issues in a separate registry; examples include reporting double‑bang force unwraps and banning lateinit, with unit tests and IDE quickfix descriptors. Android plugin/version gates control whether lint ships with a published library.
AI-written summary · about
chapters (14)
- 0:00Introduction to lint checks
- 1:26History and philosophy of lint
- 3:55Goal and challenges of enabling lint
- 5:20Configuring lint with XML files
- 7:27Suppressing and ignoring lint warnings
- 8:33Baseline and annotations for lint
- 10:20Android lint for Kotlin modules
- 11:24Lint publish option in libraries
- 12:27KTLint and custom lint rules
- 13:30How Android lint works under the hood
- 16:19Writing custom lint detectors
- 18:47Testing custom lint rules
- 20:12Quick fixes in lint checks
- 21:17Summary and next steps
related talks
41mKotlin Static Analysis with Android Lint
21mMastering Code Quality: A Deep Dive into Custom Linting for Android Developers
37mKotlin on Code Quality Tools
20mClean Code Base: Harnessing the Power of Android Lint and Custom Rules
46mLint for Life: Your Customizable Guard On the Go
22mKotlin on Code Quality Tools
44mLint. What, Why, How?
29mLint to the Finish Line