Re: [DISCUSS] Issues with heterogeneity of the code

+1 for keeping the tabs vs space for now. When I start working on Flink I was itching to move to spaces indentation since that makes reader consistent. But that was the choice by preference made early on and I think we could keep it and add as exception in Java code style. Scala, on the other han

Re: [DISCUSS] Issues with heterogeneity of the code

I'm against changing the indentation, for the same reasons as Stephan listed. In my opinion, the codebase has grown too large to "just" switch the indentation or the entire code style (to the google style or whatever). We have 235870 LOC of Java and 24173 LOC of Scala. Therefore, I'm proposing to

Re: [DISCUSS] Issues with heterogeneity of the code

I agree, if we set p a new project, we should use space indentation. Should we really refactor 300k lines of code? Would be massive. Also: The history would basically show a single committer for all code. Git blame (for error tracing) would become useless. On Wed, Mar 18, 2015 at 3:49 PM, Alexan

Re: [DISCUSS] Issues with heterogeneity of the code

Massive +1 for switching to space indention. Makes the code render consistently across various viewers (e.g. Github UI, Apache infrastructure, IDEs). 2015-03-18 1:29 GMT+01:00 Fabian Hueske : > Touching every file of the code would also be a good opportunity to switch > from tab to space indentio

Re: [DISCUSS] Issues with heterogeneity of the code

Touching every file of the code would also be a good opportunity to switch from tab to space indention. So if we enforce a strict style, we could also address this issue which causes discussions every now and then. 2015-03-16 21:53 GMT+01:00 Aljoscha Krettek : > No, but I don't know whether that'

Re: [DISCUSS] Issues with heterogeneity of the code

No, but I don't know whether that's possible. The style guide prescribes, for example, this: def foo( a: Int, b: String, c: String) for methods with long parameter lists while a lot of people do this: def foo(a: Int, b: String, c: String) (IntelliJ also does this)

Re: [DISCUSS] Issues with heterogeneity of the code

Do we already enforce the official Scala style guide strictly? On Mon, Mar 16, 2015 at 4:57 PM, Aljoscha Krettek wrote: > I'm already always sticking to the official Scala style guide, with the > exception of 100 line length. > On Mar 16, 2015 3:27 PM, "Till Rohrmann" wrote: > > > +1 for strict

Re: [DISCUSS] Issues with heterogeneity of the code

I'm already always sticking to the official Scala style guide, with the exception of 100 line length. On Mar 16, 2015 3:27 PM, "Till Rohrmann" wrote: > +1 for stricter Java code styles. I haven't looked into the Google Code > Style but maybe we make it easier for new contributors if we apply a co

Re: [DISCUSS] Issues with heterogeneity of the code

+1 for stricter Java code styles. I haven't looked into the Google Code Style but maybe we make it easier for new contributors if we apply a coding style which is somehow known. +1 for line length of 100 for Scala code. I think it makes code review on GitHub easier. For the Scala style, we could

Re: [DISCUSS] Issues with heterogeneity of the code

+1 for the stricter Java code styles. We should not forget about providing code formatter settings for Eclipse and Intellij IDEA (as mentioned above). That would help a lot. (Of course if we'll use Google Code Style, they already provide such files

Re: [DISCUSS] Issues with heterogeneity of the code

+1 for not limiting the line length. Everyone should have a good sense to break lines. When in exceptional cases people violate this, it is usually for a good reason. On Mon, Mar 16, 2015 at 2:18 PM, Maximilian Michels wrote: > +1 for enforcing a more strict Java code style. However, let's not >

Re: [DISCUSS] Issues with heterogeneity of the code

+1 for not limiting the line length. 2015-03-16 14:39 GMT+01:00 Stephan Ewen : > +1 for not limiting the line length. Everyone should have a good sense to > break lines. When in exceptional cases people violate this, it is usually > for a good reason. > > On Mon, Mar 16, 2015 at 2:18 PM, Maximili

Re: [DISCUSS] Issues with heterogeneity of the code

+1 for enforcing a more strict Java code style. However, let's not introduce a line legth of 100 like in Scala. I think that's hurting readability of the code. On Sat, Mar 14, 2015 at 4:41 PM, Ufuk Celebi wrote: > On Saturday, March 14, 2015, Aljoscha Krettek wrote: > > > I'm in favor of strict

Re: [DISCUSS] Issues with heterogeneity of the code

On Saturday, March 14, 2015, Aljoscha Krettek wrote: > I'm in favor of strict coding styles. And I like the google style. +1 I would like that. We essentially all agree that we want more homogeneity and I think strict rules are the only way to go. Since this is a very subjective matter it makes

Re: [DISCUSS] Issues with heterogeneity of the code

I'm in favor of strict coding styles. And I like the google style. But I can adapt. 😀 On Mar 13, 2015 11:26 PM, "Henry Saputra" wrote: > Agree. > > We have make decision either to play tight or loose on the code style and > guide. > Once the codebase is getting too large and more committers comi

Re: [DISCUSS] Issues with heterogeneity of the code

Agree. We have make decision either to play tight or loose on the code style and guide. Once the codebase is getting too large and more committers coming in then it would be too late. We can not have our cake and eat it too. Looking forward to what others think since I already have my 2-cents ou

Re: [DISCUSS] Issues with heterogeneity of the code

I personally find the Google code style to be too strict/detailed. Loosening it by dropping certain rules makes only sense if the deviation does not become to large. My major concern with adding a such strict code style is that all open PRs would become invalid. We could try to reduce that effect

Re: [DISCUSS] Issues with heterogeneity of the code

Regarding style, yes, we already have them in place but they are very loose, especially in Java. I guess it is a "no good deed goes unpunished" scenario. To tighten up the style rules, for example following Google Java style with some documented exceptions, will require massive code changes. But w

Re: [DISCUSS] Issues with heterogeneity of the code

We already have checkstyle for Java and Scala in place (with marking violations a breaking the build). The rules in Java are very loose, though. We may make them stricter. Would require extensive passes over a lot of code, though, to fix this. The other things (choice of library) seem to be well

Re: [DISCUSS] Issues with heterogeneity of the code

Thanks for bringing up the discussions, Stephan. Ufuk and Till had brought up some ideas to solve the example of issues you mentioned in the original thread. So In the nutshell, we need to have more strick style and rules checking for the code to help contributors to submit code change and maintai

Re: [DISCUSS] Issues with heterogeneity of the code

I also agree that we have too many different ways of doing things. A set of common rules/ways would definitely be beneficial for the project. Concerning the command line parsing: I thought that Alexander Alexandrov wanted to unify the command line parsing by replacing both tools with a better one.

Re: [DISCUSS] Issues with heterogeneity of the code

Hey Stephan, On 08 Mar 2015, at 23:17, Stephan Ewen 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. Valida

Re: [DISCUSS] Issues with heterogeneity of the code

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 : > Hi everyone! > > I would like to start an open discussion about some issue with the > hete

[DISCUSS] Issues with heterogeneity of the code

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 l