flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szabó Péter <nemderogator...@gmail.com>
Subject Re: [DISCUSS] Issues with heterogeneity of the code
Date Mon, 09 Mar 2015 07:24:17 GMT
I agree. A unified rule-set for code style & formatting would make new
contributions easier. There should be also a configuration guide for
different IDEs.

Peter

2015-03-08 23:17 GMT+01:00 Stephan Ewen <sewen@apache.org>:

> Hi everyone!
>
> I would like to start an open discussion about some issue with the
> heterogeneity of the Flink code base.
>
> We have, since the beginning in Apache (and even since we started the
> predecessor project, Stratosphere) refrained from strictly enforcing
> conventions like formatting, style, or libraries. I like the idea behind
> it, that committers and contributors are not forced into a corset of
> hundreds of rules before they can contribute something.
>
> As the project is growing, more and more people with different backgrounds
> have joined, and the project has grown a bit heterogeneous in several
> parts. In many cases, not necessarily due to need for different
> functionality, but simply due to "roll your own style". I think this is
> starting to become a bit of an issue.
>
> Here are a few examples:
>
>  - Parameter checking is sometimes done with commons-lang3, commons-lang,
> or guava
>
>  - Command line parsing is sometimes done with commons-cli, sometimes with
> scopt.
>
>  - Code styles are quite different from commit to commit. Spaces,
> indentations, braces. Not a critical thing, but seems to encourage people
> to reformat other people's code, whenever the pass over it, which should be
> avoided (cluttered diffs, may introduce new bugs actually)
>
>  - Some projects are mixed Java/Scala, which is not perfectly supported by
> the tools so far. It also needs many "fromJava / toJava" conversions and
> makes the entry hurdle into the project higher.
>
>  - Tests are sometimes written as Java Unit tests, sometimes as Scala Unit
> tests (method style), sometimes as Scala Unit Tests (grammar style).
>
> Not all things need to be unified across the entire Flink code base. But it
> becomes harder to switch between projects, even for seasoned Flinksters.
> And it becomes a hurdle for new contributors, which is very critical.
>
> I, personally, would like to encourage people to keep this in mind. Easier
> understanding of the code and easier entry for newcomers (for which a
> certain homogeneity helps quite a bit) should have a higher priority than
> the desire to stick to the personal favorite code style or library. This is
> a big community effort, after all.
>
> That said, we should not, of course, block of the use of new
> libraries/languages/features when they have significant benefit over the
> existing state.
>
> I am eager to hear opinions!
>
> Stephan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message