Hey Grant, As you know I think this is definitely valuable. My take:
1. The choice of rules is really important and it's a good plan to be conservative initially (as you suggested) 2. We should only use errors, not warnings 3. To make the previous one feasible, the rules we enable must not have false positives (or they must be _really_ rare and with a reasonable workaround). Ismael On Fri, Jan 8, 2016 at 5:18 PM, Grant Henke <[email protected]> wrote: > A while back I did a some preliminary work on KAFKA-2423: Introduce > ScalaStyle. There is a pull request here: > https://github.com/apache/kafka/pull/560. The important content for review > is the rule set defined in scalastyle_config.xml. > > I know complete consensus on something like this may not be feasible, but I > think there is value in defining some basic style rules to expedite the > patch review process and improve code readability, clarity, and quality. > The Java Checkstyle rules added to Kafka have worked well, and I think > having similar rules for Scala are important. > > If there are no major oppositions to the rules, I would like to first: > > 1. Add an optional build task to check the code for ScalaStyle rule > violations > 2. Fix the very basic violations (whitespace, line length, etc) > 3. Over time fix more impactful violations > > During this time period we can also identify if the rules are too strict, > annoying or need to be adjusted. Once the issues are fixed we can then run > ScalaStyle checks as a part of the build to be sure no new violations > occur. > > Do we agree these checks would be valuable? Do the rules and approach > proposed in my pull request seam reasonable? > > Thanks, > Grant > -- > Grant Henke > Software Engineer | Cloudera > [email protected] | twitter.com/gchenke | linkedin.com/in/granthenke >
