Will not the code style be applied on save to any user-modified file? So this will clutter PRs and overwrite history.
On Wed, Feb 22, 2017 at 6:19 AM, Dawid Wysakowicz < wysakowicz.da...@gmail.com> wrote: > 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. > >>>>> > >>>>> > > >
