Re: Scala Style Template
We could help this by having shorter local and input argument names and
better timing for the line wrapping.
We already have separate code style for java, for example keeping tabs
instead of spaces, and scala because java code more verbose and declarative
compare to scala.
I am ok with Java do not have max char per line rule but would like to keep
Scala max line rule, at least for now. If 100 too restrictive we could try
relax it to 120 or 140 to see if it helps.
On Wednesday, February 18, 2015, Robert Metzger rmetz...@apache.org wrote:
I don't want to remove the rule to encourage people to write ugly scala
code ;)
Also, I hope its the exception to use more than 100 chars.
But there are some cases where it is really okay to have longer lines (for
example exception messages or method signatures in some cases).
I agree with Stephan that its sometimes harder to understand the Scala code
due to the rule. For example:
def startActorWithConfiguration(hostname: String, taskManagerName: String,
configuration: Configuration,
localAkkaCommunication: Boolean,
localTaskManagerCommunication: Boolean)
(implicit system: ActorSystem) = {
val (connectionInfo, jobManagerURL, taskManagerConfig,
networkConnectionConfiguration) =
parseConfiguration(hostname, configuration, localAkkaCommunication,
localTaskManagerCommunication)
startActor(taskManagerName, connectionInfo, jobManagerURL,
taskManagerConfig,
networkConnectionConfiguration)
}
Would be nicer like this:
def startActorWithConfiguration(hostname: String, taskManagerName: String,
configuration: Configuration,
localAkkaCommunication: Boolean,
localTaskManagerCommunication: Boolean)
(implicit system: ActorSystem) = {
val (connectionInfo, jobManagerURL, taskManagerConfig,
networkConnectionConfiguration) =
parseConfiguration(hostname, configuration,
localAkkaCommunication, localTaskManagerCommunication)
startActor(taskManagerName, connectionInfo, jobManagerURL,
taskManagerConfig, networkConnectionConfiguration)
}
The Java checkstyle isn't very strict as well and I have the impression
that our code is still very readable.
Also, we have our pull-request reviewing system for spotting exactly such
cases.
So I'm hereby voting to remove the rule.
On Wed, Feb 18, 2015 at 4:09 PM, Henry Saputra henry.sapu...@gmail.com
javascript:;
wrote:
Ah seemed like kafka has taken out the max line rule.
I prefer to keep the max char lines, maybe making it larger than 100,
especially with Scala code.
On Wednesday, February 18, 2015, Henry Saputra henry.sapu...@gmail.com
javascript:;
wrote:
I would argue it is helpful especially if you use text editor like vim
or
even GitHub diff page.
Most modern scala projects like spark and kafka also enforce the rule.
- Henry
On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org
javascript:;
javascript:_e(%7B%7D,'cvml','se...@apache.org javascript:;');
wrote:
It is true, you can write endless chains of functions in Scala that
become
hard to read, which should be prevented.
In my opinion, line length limits are not a good tool to do that. In
most
cases they simply introduce linebreaks between constant names and
parameters
which hurt code readability more than they help.
On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
Sorry Robert and all, pressed Send button too early =(
One of the main reasons to keep the max 100 chars line (or 120) is
to
make sure that the code is readable an understandable, which in
Scala
you can easily get the code to be complicated and in a single line.
- Henry
[1] http://www.scalastyle.org/rules-0.1.0.html
On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
Stephan was taking about imports statements.
I want to keep line length to 100 or 120.
Code that is longer than 100 char per line need to be revisited.
On Tuesday, February 17, 2015, Robert Metzger
rmetz...@apache.org javascript:;
wrote:
I agree with Stephan that we should remove the scalastyle rule
enforcing
lines of 100 characters length.
On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
@Stephan - sure I could work on it. Been wanting to do it for a
while.
No, it is not the checkstyle issue.
- Henry
On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org
javascript:;
wrote:
Yes, the hadoopcompatibility is a bit long, I agree
Re: Scala Style Template
It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
I would argue it is helpful especially if you use text editor like vim or even GitHub diff page. Most modern scala projects like spark and kafka also enforce the rule. - Henry On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org wrote: It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org javascript:; wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org javascript:; wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org javascript:; wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org javascript:; wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org javascript:; wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
Ah seemed like kafka has taken out the max line rule. I prefer to keep the max char lines, maybe making it larger than 100, especially with Scala code. On Wednesday, February 18, 2015, Henry Saputra henry.sapu...@gmail.com wrote: I would argue it is helpful especially if you use text editor like vim or even GitHub diff page. Most modern scala projects like spark and kafka also enforce the rule. - Henry On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org javascript:_e(%7B%7D,'cvml','se...@apache.org'); wrote: It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
Oh, since we are using tabs I think they are counted as one character? On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org javascript:; wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org javascript:; wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org javascript:; wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org javascript:; wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
