flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: Scala Style Template
Date Wed, 18 Feb 2015 16:55:34 GMT
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 <rmetzger@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.saputra@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.saputra@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 <sewen@apache.org
> <javascript:;>
> > > <javascript:_e(%7B%7D,'cvml','sewen@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.saputra@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.saputra@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 <
> rmetzger@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.saputra@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 <sewen@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.saputra@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
<
> > >> > trohrmann@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 <
> > >> sewen@apache.org <javascript:;>>
> > >> > >> > wrote:
> > >> > >> > >> >
> > >> > >> > >> >> Excluding the imports sounds like
a good idea.
> > >> > >> > >> >>
> > >> > >> > >> >> On Sun, Jan 4, 2015 at 10:30 PM, Henry
Saputra <
> > >> > >> > henry.saputra@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 <
> > sewen@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
> > >> > >> > >> >> > >
> > >> > >> > >> >> >
> > >> > >> > >> >>
> > >> > >> > >>
> > >> > >> >
> > >> >
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message