Enforce consistent usage of braces in when entries. In case a when statement contains at least one when entry which uses braces around the body of the entry, then all when entries should use braces.
Braces are helpful for following reasons:
Bodies of the when-conditions are all aligned at same column position
Closing braces helps in separating the when-conditions
This rule is not incorporated in the Kotlin Coding conventions, nor in the Android Kotlin Styleguide. It is based on similar behavior in enforcing consistent use of braces in if-else statements. As of that the rule is only enabled automatically for code style ktlint_official. It can be enabled explicitly for other code styles.
Closes #2557
Checklist
Before submitting the PR, please check following (checks which are not relevant may be ignored):
[X] Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
[X] At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
[X] Tests are added
[X] KtLint format has been applied on source code itself and violations are fixed
[X] PR title is short and clear (it is used as description in the release changelog)
[X] Snapshot documentation in case documentation is to be released together with a code change
[ ] Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master
Description
Add new rule
when-entry-bracingEnforce consistent usage of braces in when entries. In case a when statement contains at least one when entry which uses braces around the body of the entry, then all when entries should use braces.
Braces are helpful for following reasons:
This rule is not incorporated in the Kotlin Coding conventions, nor in the Android Kotlin Styleguide. It is based on similar behavior in enforcing consistent use of braces in if-else statements. As of that the rule is only enabled automatically for code style
ktlint_official. It can be enabled explicitly for other code styles.Closes #2557
Checklist
Before submitting the PR, please check following (checks which are not relevant may be ignored):
Closes #<xxx>orFixes #<xxx>(replace<xxx>with issue number)Documentation is updated. See difference between snapshot and release documentation