You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Pat Ferrel <pa...@occamsmachete.com> on 2014/06/19 19:03:27 UTC
Scala style questions
I noticed that some of the Scala code is like this:
val columnIDs = interactions.map({ case (_, columnID) => columnID}).distinct().collect()
but as I read the Scala style guide it should use infix notation like this
val columnIDs = interactions map ({ case (_, columnID) => columnID}) distinct() collect()
It seems that the former style, familiar in Java, may have side effects in Scala, but perhaps I’m missing some Scala subtlety? I appears that both work correctly in some tests I did.
http://docs.scala-lang.org/style/method-invocation.html#higherorder_functions
Before changing all my code am I reading this correctly?
Re: Scala style questions
Posted by Ted Dunning <te...@gmail.com>.
On Sat, Jun 21, 2014 at 9:12 AM, Pat Ferrel <pa...@gmail.com> wrote:
> Unless someone has a strong counter reason I’m leaning towards using line
> length limits when convenient and not when I judge them less readable. I do
> plan to follow several other Scala style guidelines that I don’t especially
> like, because there is merit to the consistency argument.
>
My feeling is that consistent style is good except when it isn't.
On the other hand, it is good more often than most people writing code
think because it is the readers, not the writers who matter most. No
matter what the writer things readability means, the naive reader may have
different opinions.
Another thing about style is that it tends to generate heatful discussions
that have no good conclusions. My feeling over the years has thus tended
to prefer to just go with the flow because having any kind of flow is
better than stopping that flow to argue about style.
Probably what we should do is continue to ding on anything that is well
outside of established styles (which are not really fully defined for scala
just yet given that big projects like spark are idiosyncratic). Then if
the author feels strong and has an argument better than laziness, we can go
with the author.
Re: Scala style questions
Posted by Pat Ferrel <pa...@gmail.com>.
I think there are reasonable counter examples that will account for your commendable desire for commenting (like putting comments inside the { } and outside the whole chained process if it is too trivial for { }. There are several other places that we are using Java type style rather than Scala but don’t see the obvious benefit to changing and really don’t want to argue style when we have bigger work.
However while we are talking about exceptions, the line length (100 chars or so) really bothers me. I’ve had an editor that auto-wraps for several years now. :-) I think all the major terminal based editors have ways to enable auto-wraping too. When you combine auto-wrap with shorter line lengths the results can become much less readable and harder to maintain when changes are needed. This especially true of long strings where you have to insert “+"
foo(“some long nicely” +
“descriptive line “ +
“of text.”)
1) this is asking for refactor errors, missing spaces, notice no space between “nicely” and “descriptive"
2) much less readable than:
foo(“some long nicely descriptive line of text.”)
even with auto-wrap.
3) in Scala there are times when EOL does not effect semantics and times when it does since the end of an expression is not set by a “;” This makes the line breaking prone to possible semantic errors. Breaking where you fully understand the semantics is fine but where keeping on one line seems to create something more readable, as where the expression is one logical operation, seems worth the exception.
I keep getting dinged in reviews for line length violations and so I went back and applied the rule of 100 chars strictly to one file. The result IMO was worse than the original.
Unless someone has a strong counter reason I’m leaning towards using line length limits when convenient and not when I judge them less readable. I do plan to follow several other Scala style guidelines that I don’t especially like, because there is merit to the consistency argument.
On Jun 19, 2014, at 11:51 AM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
On Thu, Jun 19, 2014 at 10:03 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> but as I read the Scala style guide it should use infix notation like this
>
> val columnIDs = interactions map ({ case (_, columnID) => columnID})
> distinct() collect()
>
Well they are supposed to be an authoritative source on this so they are
correct by definition.
But this style has complication.
(1) First, if you want to have a readable code with comments, and explain
absolutely everything you do, like i prefer to do it, it is easy to see
that infix notation simply doesn't compile:
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID})
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
So i am forced to use dots before "map" etc here. Which is what i do.
(2) Once i started using dots, there's usually no way to mix in infix later
even if i wanted to put on the same line, so i use dot again :
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID}) distinct() // syntax error
So too many exception to infix style, i dropped it except for where i have
a clear operator like A * B
(3) keep working . Usually ( is not needed if { is also used
val columnIDs = interactions
// I want to run some map here
.map {
case (_, columnID) => columnID
}
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
(4) I usually avoid placeholders, i.e. i'd rather write
interactions
.map { p =>
p.value
}
than
interactions
.map(_.value)
(5) Incidentally, partially defined function in this example used to
disassble structure into explicitly named components. It is not what
partially defined function was created for, and it can cause
NoMatchException (or whatever its name), but it turns incredibly useful for
disassembling values. Hence prefrered style for e.g. mapBlock notation
drmA.mapBlock() {
case (keys, block => .
...
}
(5) I think Spark presentation didn't use infix notation even in single
line,
Either way, over the years i have strongly adopted at least throughly
commented step-by-step style as in (1) and explicit parameter naming
(albeit at cost of a partially defined function) as in (4) and (5). I still
sometimes slip on other points.
Re: Scala style questions
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
On Thu, Jun 19, 2014 at 10:03 AM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>
> but as I read the Scala style guide it should use infix notation like this
>
> val columnIDs = interactions map ({ case (_, columnID) => columnID})
> distinct() collect()
>
Well they are supposed to be an authoritative source on this so they are
correct by definition.
But this style has complication.
(1) First, if you want to have a readable code with comments, and explain
absolutely everything you do, like i prefer to do it, it is easy to see
that infix notation simply doesn't compile:
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID})
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
So i am forced to use dots before "map" etc here. Which is what i do.
(2) Once i started using dots, there's usually no way to mix in infix later
even if i wanted to put on the same line, so i use dot again :
val columnIDs = interactions
// I want to run some map here
.map ({ case (_, columnID) => columnID}) distinct() // syntax error
So too many exception to infix style, i dropped it except for where i have
a clear operator like A * B
(3) keep working . Usually ( is not needed if { is also used
val columnIDs = interactions
// I want to run some map here
.map {
case (_, columnID) => columnID
}
// I want to do distinct here
.distinct()
// I want to collect here
.collect()
(4) I usually avoid placeholders, i.e. i'd rather write
interactions
.map { p =>
p.value
}
than
interactions
.map(_.value)
(5) Incidentally, partially defined function in this example used to
disassble structure into explicitly named components. It is not what
partially defined function was created for, and it can cause
NoMatchException (or whatever its name), but it turns incredibly useful for
disassembling values. Hence prefrered style for e.g. mapBlock notation
drmA.mapBlock() {
case (keys, block => .
...
}
(5) I think Spark presentation didn't use infix notation even in single
line,
Either way, over the years i have strongly adopted at least throughly
commented step-by-step style as in (1) and explicit parameter naming
(albeit at cost of a partially defined function) as in (4) and (5). I still
sometimes slip on other points.
Re: Scala style questions
Posted by Pat Ferrel <pa...@occamsmachete.com>.
Thanks, I think I’ll leave the dot notation for now. I use a Scala lib that has infix in its examples so will follow their style when using it. They are both supported after all.
On Jun 19, 2014, at 10:23 AM, Nick Pentreath <ni...@gmail.com> wrote:
Using infix notation is exactly that - notation. There is no effect on code etc.
I also personally tend to favour the more verbose dot notation (perhaps due to java background ). More readable IMO with the exception of DSLs where it can be quite nice.
FWIW Spark prefers dot notation for readability and also it is more familiar for people coming from a Java background and I believe this approach is a must for mixed Scala/Java projects.
One style issue I see is map with case doesn't need parentheses, ie you can do:
val columnIDs = interactions.map { case (_, columnID) => columnID }.distinct().collect()
Which is more readable too in my view :)
—
Sent from Mailbox
On Thu, Jun 19, 2014 at 7:12 PM, Sean Owen <sr...@gmail.com> wrote:
> For what it's worth: I really prefer the dot notation myself. Yeah
> it's more Java-like and I think that's a good thing for clarity.
> The style guide seems to in general discourage infix except for
> symbolic operators, and also a special case of higher-order functions.
> But the example they give seems to turn on an ambiguity introduced by
> spaces, and nothing to do with infix. I'm confused. But I like dots.
> http://docs.scala-lang.org/style/method-invocation.html
> I don't know of any reason using dots would create a weird or subtle effect.
> On Thu, Jun 19, 2014 at 6:03 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>> I noticed that some of the Scala code is like this:
>>
>> val columnIDs = interactions.map({ case (_, columnID) => columnID}).distinct().collect()
>>
>> but as I read the Scala style guide it should use infix notation like this
>>
>> val columnIDs = interactions map ({ case (_, columnID) => columnID}) distinct() collect()
>>
>> It seems that the former style, familiar in Java, may have side effects in Scala, but perhaps I’m missing some Scala subtlety? I appears that both work correctly in some tests I did.
>> http://docs.scala-lang.org/style/method-invocation.html#higherorder_functions
>>
>> Before changing all my code am I reading this correctly?
>>
>>
Re: Scala style questions
Posted by Nick Pentreath <ni...@gmail.com>.
Using infix notation is exactly that - notation. There is no effect on code etc.
I also personally tend to favour the more verbose dot notation (perhaps due to java background ). More readable IMO with the exception of DSLs where it can be quite nice.
FWIW Spark prefers dot notation for readability and also it is more familiar for people coming from a Java background and I believe this approach is a must for mixed Scala/Java projects.
One style issue I see is map with case doesn't need parentheses, ie you can do:
val columnIDs = interactions.map { case (_, columnID) => columnID }.distinct().collect()
Which is more readable too in my view :)
—
Sent from Mailbox
On Thu, Jun 19, 2014 at 7:12 PM, Sean Owen <sr...@gmail.com> wrote:
> For what it's worth: I really prefer the dot notation myself. Yeah
> it's more Java-like and I think that's a good thing for clarity.
> The style guide seems to in general discourage infix except for
> symbolic operators, and also a special case of higher-order functions.
> But the example they give seems to turn on an ambiguity introduced by
> spaces, and nothing to do with infix. I'm confused. But I like dots.
> http://docs.scala-lang.org/style/method-invocation.html
> I don't know of any reason using dots would create a weird or subtle effect.
> On Thu, Jun 19, 2014 at 6:03 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
>> I noticed that some of the Scala code is like this:
>>
>> val columnIDs = interactions.map({ case (_, columnID) => columnID}).distinct().collect()
>>
>> but as I read the Scala style guide it should use infix notation like this
>>
>> val columnIDs = interactions map ({ case (_, columnID) => columnID}) distinct() collect()
>>
>> It seems that the former style, familiar in Java, may have side effects in Scala, but perhaps I’m missing some Scala subtlety? I appears that both work correctly in some tests I did.
>> http://docs.scala-lang.org/style/method-invocation.html#higherorder_functions
>>
>> Before changing all my code am I reading this correctly?
>>
>>
>>
Re: Scala style questions
Posted by Sean Owen <sr...@gmail.com>.
For what it's worth: I really prefer the dot notation myself. Yeah
it's more Java-like and I think that's a good thing for clarity.
The style guide seems to in general discourage infix except for
symbolic operators, and also a special case of higher-order functions.
But the example they give seems to turn on an ambiguity introduced by
spaces, and nothing to do with infix. I'm confused. But I like dots.
http://docs.scala-lang.org/style/method-invocation.html
I don't know of any reason using dots would create a weird or subtle effect.
On Thu, Jun 19, 2014 at 6:03 PM, Pat Ferrel <pa...@occamsmachete.com> wrote:
> I noticed that some of the Scala code is like this:
>
> val columnIDs = interactions.map({ case (_, columnID) => columnID}).distinct().collect()
>
> but as I read the Scala style guide it should use infix notation like this
>
> val columnIDs = interactions map ({ case (_, columnID) => columnID}) distinct() collect()
>
> It seems that the former style, familiar in Java, may have side effects in Scala, but perhaps I’m missing some Scala subtlety? I appears that both work correctly in some tests I did.
> http://docs.scala-lang.org/style/method-invocation.html#higherorder_functions
>
> Before changing all my code am I reading this correctly?
>
>
>