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