Add more scalastyle rules #1142
Conversation
The intention of this is so that potential contributors see a consistent style and so that they can check the scalastyle input and hopefully avoid reviewers leaving nitpicky formatting comments on PRs.
Current coverage is 88.80%
|
|
Maybe we could also add a rule to check we write type class instead of typeclass, so we don't need to clean this up regularly like in #1149. |
|
@peterneyens that is an excellent idea. I'm very inconsistent on this point. I think that there are a couple things we'll have to keep in mind.
|
Instead of "typeclass" -- this decision was made in typelevel#441.
|
@peterneyens updated to include "type class" rule. |
|
Maybe we could also remove the |
ceedubs
changed the title
|
#845 has been merged and I've updated this PR. I think it's ready for review/merge. |
|
👍 LGTM |
| @@ -27,7 +27,7 @@ final case class OneAnd[F[_], A](head: A, tail: F[A]) { | |||
| */ | |||
| def filter(f: A => Boolean)(implicit F: MonadCombine[F]): F[A] = { | |||
| val rest = F.filter(tail)(f) | |||
| if (f(head)) F.combineK(F.pure(head), rest) else rest | |||
| if(f(head)) F.combineK(F.pure(head), rest) else rest | |||
There was a problem hiding this comment.
Later in this diff, spaces are inserted between if and (, for example here. Can we add a scalastyle rule to make this consistent?
There was a problem hiding this comment.
Wow good catch. The other places were caught by EnsureSingleSpaceAfterTokenChecker. It seems to me like a scalastyle bug that this particular place isn't caught by that rule.
|
I made a minor comment about spaces after |
This should be caught by `EnsureSingleSpaceAfterTokenChecker` but for some reason it's not in some places.
|
@fthomas I've added a rule for space after |
The intention of this is so that potential contributors see a consistent
style and so that they can check the scalastyle output and hopefully
avoid reviewers leaving nitpicky formatting comments on PRs.
I'd like to wait until #845 is merged before we merge this one so we don't potentially cause yet another merge conflict in that PR. I wanted to go ahead and submit this so that I don't forget to though.