Thanks for wrapping up the discussion, Fabian!
The tab size is adjustable in all the viewers I know of, e.g. DataSet
with tab size of 2 on GitHub:
https://github.com/apache/flink/blob/master/flink-java/src/main/java/org/apache/flink/api/java/DataSet.java?ts=2
You can even even use "less -x2 Source
I wouldn't stop with GitHub - the main benefit for spaces is that the code
looks the same on all viewers because it does not depend on a user-specific
parameter (the size of the tab).
2015-11-09 14:02 GMT+01:00 Ufuk Celebi :
> Minor thing in favour of spaces: Reviewability on GitHub is improved (
Minor thing in favour of spaces: Reviewability on GitHub is improved (they use
8 spaces for tabs and line length of 120, which often results in too long
lines).
> On 09 Nov 2015, at 13:53, Fabian Hueske wrote:
>
> I don't see other benefits except maybe being closer to the vanilla Google
> sty
I don't see other benefits except maybe being closer to the vanilla Google
style.
2015-11-02 20:46 GMT+01:00 Stephan Ewen :
> I think by now virtually everyone prefers spaces if it came for free, so it
> is a matter of making an educated decision about the cost/benefit
> tradeoffs.
>
> What are t
I think by now virtually everyone prefers spaces if it came for free, so it
is a matter of making an educated decision about the cost/benefit tradeoffs.
What are the benefits of spaces in the style other than people liking the
looks of space-formatted code better (aesthetics, schmaesthetics ;-) )
Thanks for the summary Fabian.
Maybe we should have kind of a vote about this. No classical Apache vote
though, but voting for different options (so only +1), and the option
with the highest score wins? (Not sure if this is possible to do...)
About spaced vs. tabs:
> "AFAIR, nobody said to have a
OK, I'll try to summarize the discussion so far (please correct me if I got
something wrong):
Everybody is in favor of adding a stricter code style based on the Google
Java code style.
Main points of discussion are:
1) Line length
2) JavaDocs
3) Tabs vs. Spaces
-- Line length
Issue:
Google code s
I looked up if the Checkstyle plugin would also support tabs with a
fixed line length. Indeed, this is possible because a tab can be
mapped to a fixed number of spaces.
I've modified the default Google Style Checkstyle file. I changed the
indention to tabs (2 spaces) and increased the line length
2 spaces is the convention that's followed on Mahout and Oryx.
On Mon, Oct 26, 2015 at 1:42 PM, Till Rohrmann wrote:
> Concerning question 2 Tabs vs. Spaces, in case of spaces we would have to
> decide on the number of spaces, too. The Google Java style says to use a 2
> space indentation, which
Concerning question 2 Tabs vs. Spaces, in case of spaces we would have to
decide on the number of spaces, too. The Google Java style says to use a 2
space indentation, which is in my opinion sufficient to distinguish
different indentations levels from each other. Furthermore, it would save
some spa
+1 for adding restriction for Javadoc at least at the header of public
classes and methods.
We did the exercise in Twill and seemed to work pretty well.
On Fri, Oct 23, 2015 at 1:34 AM, Maximilian Michels wrote:
> I don't think lazily adding comments will work. However, I'm fine with
> adding al
Yes. I think that's a good compromise. Additionally, I vote for a
"deadline" (or "target date") to get those JIRAs done (even if we cannot
enforce it) to not get "trapped" by the lazy approach.
On 10/23/2015 02:12 PM, Fabian Hueske wrote:
> Which basically defaults back to lazily adding JavaDocs (
Which basically defaults back to lazily adding JavaDocs (with some
bookkeeping).
I'd be +1 for that.
2015-10-23 14:09 GMT+02:00 Matthias J. Sax :
> A "deadline" is not really forcible.
>
> However, if we have a JIRA for each module, we can enable JavaDoc
> enforcement when the JIRA is resolved.
A "deadline" is not really forcible.
However, if we have a JIRA for each module, we can enable JavaDoc
enforcement when the JIRA is resolved. And we should discuss the
progress about those tickets regularly (to hopefully find volunteers to
resolve them) and use a special tag for them.
On 10/23/20
And who should be "forced" to write the docs before the deadline passes?
That's not going to work either, IMO.
2015-10-23 13:13 GMT+02:00 Matthias J. Sax :
> I don't care about line length.
>
> Still prefer whitespaces because it gives aligned indention for line
> break in method calls (remember
I don't care about line length.
Still prefer whitespaces because it gives aligned indention for line
break in method calls (remember my example) But I would not vote -1 for
keeping tabs either.
About JavaDocs: I agree with Max that lazy adding will not fix the
problem. There should be some enforc
I am with Vasia.
Are spaces so important that we want to effectively wipe out the entire
commit history?
On Fri, Oct 23, 2015 at 11:51 AM, Vasiliki Kalavri <
vasilikikala...@gmail.com> wrote:
> Hey,
>
> sorry I haven't replied so far. I was enjoying the thread tough :P
>
> I'm +1 for 120 line le
Hey,
sorry I haven't replied so far. I was enjoying the thread tough :P
I'm +1 for 120 line length and tabs. I wouldn't voice a -1 for spaces, but
it seems to me like an unnecessary change that would touch every single
Java file and without substantially improving anything.
JavaDocs by-module wi
Enforcing JavaDocs (no, by-file, by-module, global) is another open
question.
Regarding the line length, I am OK with 120 chars.
2015-10-23 11:29 GMT+02:00 Ufuk Celebi :
> I think that we have two open questions now:
>
> 1. Line length
>
> From the discussion so far, I think that no one wants 80
I think that we have two open questions now:
1. Line length
From the discussion so far, I think that no one wants 80 characters line length.
The final decision will be 100 vs. 120 characters. 120 characters is what we
have right now (for most parts), so it is fair to keep it that way, but enfor
I don't think lazily adding comments will work. However, I'm fine with
adding all the checkstyle rules one module at a time (with a jira
issue to keep track of the modules already converted). It's not going
to happen that we lazily add comments because that's the reason why
comments are missing in
+1 for the google style, but keeping tabs. I'm against a too narrow line
length limitation (at least 100)
On Thu, Oct 22, 2015 at 6:05 PM, Henry Saputra
wrote:
> Could we make certain rules to give warning instead of error?
>
> This would allow us to cherry-pick certain rules we would like peopl
Could we make certain rules to give warning instead of error?
This would allow us to cherry-pick certain rules we would like people
to follow but not strictly enforced.
- Henry
On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen wrote:
> I don't think a "let add comments to everything" effort gives u
I agree and don't think that it is possible to add good/valuable comments
to all the classes in a reasonable time frame. I would stage this effort to
add comments lazily as we touch components -or- as people are motivated to
add comments. We can add exclusions for this check per file (might be a
lo
I don't think a "let add comments to everything" effort gives us good
comments, actually. It just gives us checkmark comments that make the rules
pass.
On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske wrote:
> Sure, I don't expect it to be free.
> But everybody should be aware of the cost of addin
Sure, I don't expect it to be free.
But everybody should be aware of the cost of adding this code style, i.e.,
spending a huge amount of time on reformatting and documenting code.
Alternatively, we could drop the JavaDocs rule and make the transition
significantly cheaper.
2015-10-22 15:24 GMT+02
There ain’t no such thing as a free lunch and code style.
On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels wrote:
> I think we have to document all these classes. Code Style doesn't come
> for free :)
>
> On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske wrote:
> > Any ideas how to deal with th
I think we have to document all these classes. Code Style doesn't come
for free :)
On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske wrote:
> Any ideas how to deal with the mandatory JavaDoc rule for existing code?
> Just adding empty headers to make the checkstyle pass or start a serious
> effort t
Any ideas how to deal with the mandatory JavaDoc rule for existing code?
Just adding empty headers to make the checkstyle pass or start a serious
effort to add the missing docs?
2015-10-21 13:31 GMT+02:00 Matthias J. Sax :
> Agreed. That's the reason why I am in favor of using vanilla Google code
Agreed. That's the reason why I am in favor of using vanilla Google code
style.
On 10/21/2015 12:31 PM, Stephan Ewen wrote:
> We started out originally with mixed tab/spaces, but it ended up with
> people mixing spaces and tabs arbitrarily, and there is little way to
> enforce Matthias' specific s
We started out originally with mixed tab/spaces, but it ended up with
people mixing spaces and tabs arbitrarily, and there is little way to
enforce Matthias' specific suggestion via checkstyle.
That's why we dropped spaces alltogether...
On Wed, Oct 21, 2015 at 12:03 PM, Gyula Fóra wrote:
> I th
I think the nice thing about a common codestyle is that everyone can set
the template in the IDE and use the formatting commands.
Matthias's suggestion makes this practically impossible so -1 for mixed
tabs/spaces from my side.
Matthias J. Sax ezt írta (időpont: 2015. okt. 21., Sze,
11:46):
> I
I actually like tabs a lot, however, in a "mixed" style together with
spaces. Example:
myVar.callMethod(param1, // many more
.paramX); // the dots mark space indention
indenting "paramX" with tabs does not give nice aliment. Not sure if
this would be a feasible com
To summarize up to this point:
- All are in favour of Google check style (with the following possible
exceptions)
- Proposed exceptions so far:
* Specific line length 100 vs. 120 characters
* Keep tabs instead converting to spaces (this would translate to
skipping/coming up with some indentati
Thanks Max for checking the modifications by the Google code style.
It is very good to know, that the impact on the code base would not be too
massive. If the Google code style would have touched almost every line, I
would have been in favor of converting to spaces. However, your assessment
is a st
I think that the line length limitation and the space indentation are the
two rules which are most controversial in the Flink community because so
far it has been done completely different. Thus, they would also inflict
most of the changes. However, I think that at least the line length
limitation
I'm a little less excited about this. You might not be aware but, for
a large portion of the source code, we already follow the Google style
guide. The main changes will be tabs->spaces and 80/100 characters
line limit.
Out of curiosity, I ran the official Google Style Checkstyle
configuration to
1) yes. Been dancing this issue for a while. Let's pull the trigger. Did
the exercise with Tachyon while back and did help readability and
homogeneity of code.
2) +1 for Google Java style with documented exceptions and explanation on
why.
On Tuesday, October 20, 2015, Ufuk Celebi wrote:
> DISCL
I am in favor of Google vanilla code style.
As far as I followed the discussion there will be no style that
everybody loves, but most people agree that there should be a unique
style. Thus, adjusting Google style does not give any benefits.
-Matthias
On 10/20/2015 03:36 PM, Stephan Ewen wrote:
+1 for introducing a stricter style guide and starting with the Google
style.
Should we have a separate discussion whether we take the Google style guide
vanilla, or whether we make slight adjustments?
On Tue, Oct 20, 2015 at 3:26 PM, Till Rohrmann wrote:
> That's how I've understood Ufuk's mai
That's how I've understood Ufuk's mail. Everyone should also be aware that
the Google code style limits the number characters per line to either 80 or
100. But I guess that everyone will read it himself.
On Tue, Oct 20, 2015 at 3:15 PM, Stephan Ewen wrote:
> Just checking: Do we take Google's st
Just checking: Do we take Google's style guide as is, including spaces
instead of tabs? I like the spaces, but that will make things hard...
On Tue, Oct 20, 2015 at 3:01 PM, Gyula Fóra wrote:
> +1 for both :)
>
> Till Rohrmann ezt írta (időpont: 2015. okt. 20., K,
> 14:58):
>
> > I like the ide
+1 for both :)
Till Rohrmann ezt írta (időpont: 2015. okt. 20., K,
14:58):
> I like the idea to have a bit stricter code style which will increase code
> maintainability and makes it easier for people to go through the code.
> Furthermore, it will relieve us from code style comments while review
I like the idea to have a bit stricter code style which will increase code
maintainability and makes it easier for people to go through the code.
Furthermore, it will relieve us from code style comments while reviewing
PRs which can be quite cumbersome.
Personally, I like the Google code style. Th
+1 for both
As we are planning to restructure the maven projects at the point that
breaks the PRs anyway, so going on step further at this point in time is
reasonable for me.
On Tue, Oct 20, 2015 at 2:37 PM, Matthias J. Sax wrote:
> big +1 for both!
>
> On 10/20/2015 02:31 PM, Ufuk Celebi wrote
big +1 for both!
On 10/20/2015 02:31 PM, Ufuk Celebi wrote:
> DISCLAIMER: This is not my personal idea, but a community discussion from
> some time ago. Don't kill the messenger.
>
> In March we were discussing issues with heterogeneity of the code [1]. The
> summary is that we had a consensus to
DISCLAIMER: This is not my personal idea, but a community discussion from
some time ago. Don't kill the messenger.
In March we were discussing issues with heterogeneity of the code [1]. The
summary is that we had a consensus to enforce a stricter code style on our
Java code base in order to make i
47 matches
Mail list logo
