I also agree with Till and Chesnayl. Anyway as to "capture the current style" I have some doubts if this is possible, as it changes file to file.
Chesnay's suggestion as to were enforce the checkstyle seems reasonable to me, but I am quite new to the community :). Enabling checkstyle for particular packages is possible. 2017-02-22 12:07 GMT+01:00 Chesnay Schepler <ches...@apache.org>: > I agree with Till. > > I would propose enforcing checkstyle on a subset of the modules, basically > those that are not > flink-runtime, flink-java, flink-streaming-java. These are the ones imo > where messing with the history > can be detrimental; for the others it isn't really important imo. > (Note that i excluded scala code since i don't know the state of > checkstyle compliance there) > > For flink-runtime we could maybe (don't know if it is supported) enforce > checkstyle for all classes > under o.a.f.migration, so that at least the flip-6 code is covered. > > Similarly, enforcing checkstyle for all tests should be fine as well. > > Regards, > Chesnay > > > On 22.02.2017 11:48, Till Rohrmann wrote: > >> I think that not enforcing a code style is as good as not having any code >> style to be honest. Having an IntelliJ or Eclipse profile is nice and some >> people will probably use it, but my gut feeling is that the majority won't >> notice it. >> >> Cheers, >> Till >> >> On Wed, Feb 22, 2017 at 11:15 AM, Ufuk Celebi <u...@apache.org> wrote: >> >> Kurt's proposal sounds reasonable. >>> >>> What about the following: >>> - We try to capture the current style in an code style configuration >>> (for IntelliJ and maybe Eclipse) >>> - We provide that on the website for contributors to download >>> - We don't enforce it, but new contributions and changes are free to >>> format with this style as changes happen >>> >>> Practically speaking, this should not change much except maybe the >>> import order or whitespace after certain keywords, etc. >>> >>> >>> On Wed, Feb 22, 2017 at 4:48 AM, Kurt Young <ykt...@gmail.com> wrote: >>> >>>> +1 to provide a unified code style for both java and scala. >>>> >>>> -1 to adjust all the existing code to the new style in one step. The >>>> >>> code's >>> >>>> history contains very helpful information which can help >>>> develops to understand why these codes are added, which jira is related. >>>> This information is too valuable to lose. I think we can >>>> do the reformat thing step by step, each time when the codes being >>>> >>> changed, >>> >>>> we can adopt them to the new style. >>>> IMHO this is also the reason why the unified code style is important. >>>> >>>> >>>> Best, >>>> Kurt >>>> >>>> On Wed, Feb 22, 2017 at 5:50 AM, Dawid Wysakowicz < >>>> wysakowicz.da...@gmail.com> wrote: >>>> >>>> Hi, >>>>> I would like to resurrect the discussing ([1] >>>>> <http://apache-flink-mailing-list-archive.1008284.n3. >>>>> nabble.com/Code-style-guideline-for-Scala-td7526.html> >>>>> , [2] >>>>> <http://apache-flink-mailing-list-archive.1008284.n3. >>>>> nabble.com/Intellij-code-style-td11092.html>) >>>>> about creating unified code style(that could be imported to at least >>>>> IntelliJ and Eclipse) and corresponding stricter checkstyle rules. >>>>> >>>>> I know that the hardest part is to adjust the existing code to the new >>>>> checkstyle rules. Do you believe it would be worth the effort? All >>>>> suggestions are welcome. >>>>> >>>>> >
