For file where we don't enforce checkstyle things should work they way
they do right now.
Turn off auto-formatting, and only format code that you touched and
that's it. For these
modification we will have to check them manually in the PRs as we do now.
On 22.02.2017 16:22, Greg Hogan wrote:
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.
