The readme says that if it finds the code (if (some test) (some action) nil) it will suggest replacing it with while. I think it means when, but this isn't right; single-branched if forms are totally acceptable if the focus is on the return value. Since when has an implicit do form, it is a way of signaling to readers that side-effects are involved, while if forms are all about what value is returned. Instead consider adding a rule for replacing (if cond (do some action)) with when.
(if (some test) (some action) nil)
(if cond (do some action))
Maybe what we really need is an easy way to configure which substitutions different users prefer?
The battle continues. ;-) +1 for @AlexBaranosky's suggestion.
Is this rule causing problems? Are you getting pull requests from users who have run kibit on your project and you don't agree with the changes (I've seen this happen)? If that's the case I'd rather just remove the rule for now until I find time to revisit this project.
My apologies; I saw this issue on my way to creating #52, so perhaps the +1 wasn't especially valuable.
@jonase yeah, I would like to use Kibit on Leiningen, but the amount of noise generated from this bug makes it annoying to try it out.
I strongly disagree that this is a 'bug' of any sort. I personally prefer when for single branch ifs and would be disappointed if this got removed entirely.
I'm inclined to agree with @technomancy on this. I propose removing single-branch if -> when rules, but making them available through add-on custom rules #66. Thoughts?