[
https://issues.apache.org/jira/browse/KAFKA-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947464#comment-14947464
]
Grant Henke commented on KAFKA-2620:
------------------------------------
[~ijuma] I agree we should use Scalastyle as well. These are two complimentary
tools in that Scalastyle will break the build if you break any style rules (and
is more strict/configurable), while Scalaiform will reformat the code for
simple spacing and style issues to avoid as many breaks.
At a minimum using Scalaiform to clean a large number of Scalastyle issues may
be useful. I quickly integrated Scalastyle with the Kafka repo and with some
basic rules Kafka had 5326 issues. After Scalaiform it went down to 3206 issues
(many of those are still simple formatting issues that Scalaiform just doesn't
have rules/options to fix yet).
I had not started a discussion on the scalaStyle jira as I thought this was a
good first step, and we need to discuss the best "migration" approach like you
mentioned. We may need to set some rules as "warn" and fix them overtime
instead of in one big sweep. But we can discuss that there. I can share the
quick integration I did as well.
> Introduce Scalariform
> ---------------------
>
> Key: KAFKA-2620
> URL: https://issues.apache.org/jira/browse/KAFKA-2620
> Project: Kafka
> Issue Type: Bug
> Components: build
> Reporter: Grant Henke
> Assignee: Grant Henke
>
> Many of our reviews include nit comments related to Scala style. Adding
> [Scalariform|https://github.com/daniel-trinh/scalariform] allows us to
> reformat the code based on configurable standards at build time, ensuring
> uniform readability and a short review/commit cycle.
> I expect this will have some discussion around the rules we would like to
> include, and if we actually want to adopt this. I will submit a sample patch
> to start the discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
