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>
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>
> 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
> >> > >> > >> >> > >
> >> > >> > >> >> >
> >> > >> > >> >>
> >> > >> > >>
> >> > >> >
> >> >
> >>
> >
>
