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 <[email protected]> wrote:
On Thu, Jun 19, 2014 at 10:03 AM, Pat Ferrel <[email protected]> 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.
