Hey Stephan, On 08 Mar 2015, at 23:17, Stephan Ewen <se...@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 thingy?! > 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
