These are my opinions. There are many like them but these are mine. 😄
Inside of your dependencies block add the following: (for more details see adding more rule sets)
detektPlugins("com.github.hbmartin:hbmartin-detekt-rules:0.1.4")Then add to your detekt configuration as in the section below to activate rules. Note that the AvoidFirstOrLastOnList and AvoidMutableCollections rules require type resolution to be active.
Add below to your detekt.yml and modify to suit your needs. Only the AvoidVarsExceptWithDelegate rule has additional configuration options, where you may provide a regex to allow additional variable delegates.
HbmartinRuleSet:
AvoidFirstOrLastOnList:
active: true
AvoidMutableCollections:
active: true
AvoidVarsExceptWithDelegate:
active: true
allowedDelegates:
- 'remember\w*'
- 'mutableState\w*'
DontForceCast:
active: true
MutableTypeShouldBePrivate:
active: true
NoCallbacksInFunctions:
active: true
ignoreAnnotated: ['Composable']
allowExtensions: true
allowReceivers: true
NoNotNullOperator:
active: true
NoVarsInConstructor:
active: true
WhenBranchSingleLineOrBraces:
active: trueFinds uses of .first() or .list() on a list type. These are dangerous calls since they will throw a NoSuchElementException exception if the list is empty. Prefer to use .firstOrNull() or .lastOrNull() instead. See here for triggering and non-triggering examples.
Finds uses of mutable collections e.g. MutableList<>. These are highly likely to lead to bugs, prefer to use functional patterns to create new lists modified as needed. See here for triggering and non-triggering examples.
Finds uses of mutable var fields. These are highly likely to lead to bugs, prefer to use a Flow or some reactive type for any mutable state. There is an exception made for vars which are implemented with the delegation pattern, which is particularly common when using Compose. See here for triggering and non-triggering examples.
Finds uses of as to force cast. These are likely to lead to crashes, especially in unforeseen circumstances, prefer to safely cast with as? instead. See here for triggering and non-triggering examples.
Finds publicly exposed mutable types e.g. MutableStateFlow<>. These are likely to lead to bugs, prefer to expose a non-mutable Flow (e.g. with _mutableStateFlow.asStateFlow()) or other non-mutable type. See here for triggering and non-triggering examples.
Finds uses of callbacks in functions. This can lead to a mixed concurrency paradigm and are likely to lead to bugs or stalled threads, prefer to use a suspend function instead. Use the ignoreAnnotated configuration to allow callbacks in @Composable functions. See here for triggering and non-triggering examples.
Finds uses of !! to force unwrap. These are likely to lead to crashes, prefer to safely unwrap with ?. or ?: instead. Otherwise the Kotlin docs will make fun of you for being an NPE lover. See here for triggering and non-triggering examples.
Finds uses of var in a constructor. These are likely to lead to bugs, always use val instead. See here for triggering and non-triggering examples.
A stylistic rule that require that either a when expression be on a single line or use braces. Either case should have a single space after the arrow. See here for triggering and non-triggering examples.
- Jump in and modify this project! Start by cloning it with
git clone git@github.com:hbmartin/hbmartin-detekt-rules.git, then open it in IntelliJ and run the tests. - Read the detekt documentation to learn more about how to write rules.
- PRs and bug reports / feature requests are all welcome!
- Checked with detekt, including the ruleauthors set and, of course, running these rules on itself 😏
- Treat other people with helpfulness, gratitude, and consideration! See the JetBrains CoC
- Harold Martin - harold.martin at gmail
- Significant inspiration from kure-potlin by neeffect and Doist detekt-rules