flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ufuk Celebi <...@apache.org>
Subject Re: [DISCUSS] Issues with heterogeneity of the code
Date Mon, 09 Mar 2015 07:46:04 GMT
Hey Stephan,

On 08 Mar 2015, at 23:17, Stephan Ewen <sewen@apache.org> wrote:

> Hi everyone!
> I would like to start an open discussion about some issue with the
> heterogeneity of the Flink code base.

Thanks for bringing this up. I agree with your position. The related discussion about using
Guava vs. Validate is a good step into the right direction. In general, I think it's super
hard to get more homogeneity without enforcing rules (like in the Guava/Validate discussion).
I would be OK with trying to settle on rules and then enforcing them. But I'm not sure whether
that is what you are asking for? Are you more aiming at a "Let's keep it in mind" kind of

> 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.

I think these are easily enforceable and could also be changed manually w/o too much hassle.

> - 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)

This is something we could more strictly enforce in pull requests and generally ask people
to refrain from.

> - 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).

This is an artifact of the mixed Scala/Java discussion. I agree that this can be problematic,
but I'm not sure how to solve this as long as we mix Java/Scala in the same modules?! For
new code in the runtime, we could stick to one language. What do you propose here as a solution?

> I am eager to hear opinions!

As I've said, I agree with your points, but I think a big issue for new comers and committers
alike is missing documentation in the code. We should try to keep the discussion we had in
that regard in mind as well.

– Ufuk
View raw message