
Databricks Scala Style Guide - rxin
https://github.com/databricks/scala-style-guide
======
whateveracct
The monadic chaining section makes no mention of for-yield strangely enough.
Their example

    
    
        def getAddress(name: String): Option[String] = {
          database.get(name).flatMap { elem =>
            elem.data.get("address")
              .flatMap(Option.apply)  // handle null value
          }
        }
    

could just be

    
    
        def getAddress(name: String): Option[String] = {
          for {
            elem <- database.get(name)
            address <- elem.data.get("address")
          } yield address
        }
    

and it's way more readable than their given rewrite.

Then again, for-yield might be too magical and "can confuse programmers less
familiar with Scala," which seems to be a reason for a lot of the stylistic
decisions.

~~~
jghn
While I disagree I've seen people object to the for/yield on monads because
"it doesn't really seem like a for loop". YMMV

~~~
the_af
That's because it's not a for loop. Maybe the problem is that it's
inconsistently named.

I like for/yield because it reminds me of do-notation in Haskell, and it's
used for a similar purpose.

~~~
jghn
I agree that it's confusingly named, what I meant was that I disagree w/ those
colleagues who avoid it like the plague because of the confusing name.

I feel like it's one of those things that seems weird the first time you see
it but idioms are idioms.

------
the_af
This style guide discourages multiple parameter lists, but it doesn't mention
that they are useful for helping the compiler with type inference, as
mentioned here: [http://docs.scala-
lang.org/style/declarations.html](http://docs.scala-
lang.org/style/declarations.html) (granted, this is a bit of Scala ugliness,
but it merits discussion).

I agree with several of their recommendations, but I strongly disagree with
their general philosophy of "[feature] can confuse programmers less familiar
with Scala". It's one thing for [feature] to be genuinely confusing, and an
entirely different thing for it to be "confusing to novices / Java
programmers". In the latter case, the right course of action is to educate
them; otherwise we'd be stuck programming in Java++.

------
eranation
So far it's the best style guide I've seen for Scala. Much more pragmatic, and
actually very close to the way I naturally write Scala. I love the instruction
to avoid symbolic methods unless they are really using symbols that everyone
use (+ - / * etc...) I really hate all the ~> <|-|> <:< madness, it gives
Scala a really bad name.

I like it how they prefer JAVA_STYLE_CONSTANTS over ScalaStyleConstants and
same thing for annotations.

The instruction on Implicits is really making sense. use it if you build a DSL
or use it internally, keep the principle of least astonishment.

Great style guide. I'm adopting it. It's strict on one way, but let's you
escape if you have a reason.

The only caveat is what others have mentioned regarding monadic chaining. I
prefer to use for-yield when it's clear that I'm working with collection
transformations, nested futures, and even nested options. only when it's too
cumbersome to read I break it down to the desugared form.

~~~
saryant
> So far it's the best style guide I've seen for Scala. Much more pragmatic,
> and actually very close to the way I naturally write Scala. I love the
> instruction to avoid symbolic methods unless they are really using symbols
> that everyone use (+ - / * etc...) I really hate all the ~> <|-|> <:<
> madness, it gives Scala a really bad name.

From the official style guide:

> Symbolic Method Names: Avoid!

[http://docs.scala-lang.org/style/naming-
conventions.html#sym...](http://docs.scala-lang.org/style/naming-
conventions.html#symbolic_method_names)

------
jaytaylor
Do any of you know if there is an equivalent of gofmt for scala, e.g scalafmt?

If such a thing existed some portion of this long list of sensible conventions
wouldn't have to be memorized and/or constantly referenced and manually
enforced.

Such a tool would empower scala programmers to focus more on that that which
is most important- the functionality and logic, rather than manually applied
aesthetics.

~~~
saryant
Here's a talk cataloging them: [http://confreaks.tv/videos/pnws2014-towards-a-
safer-scala](http://confreaks.tv/videos/pnws2014-towards-a-safer-scala)

------
th0br0
It'd be overkill to submit a PR for this so: it should be "to the best OF our
knowledge" in the first line.

I wish organisations would provide IntelliJ configuration files (or similar)
when releasing such style guides as well... ;)

~~~
rxin
Thanks - fixed!

------
lmm
Lots of good sense, but a few things make the code clunkier than scala needs
to be IMO.

    
    
        try foo catch {...}
    

is readable and consistent; the idea that {} _just makes a block_ is really
useful, making try/catch, if/then and even method definitions a lot less
"magic", a lot less cluttered by ceremony.

Infix method calls can likewise read much more clearly:

    
    
        string contains "foo"
    

Try is bad, but \/ makes a better alternative to throwing an exception for
exactly the same reasons that Option is better than returning null.

------
azinman2
This style guide is great. I employ almost all of this at Empirical (my
company) and I even learned a thing or two. Very well written, and great
examples!

------
sirseal
This style guide is depressing... The author's complete oversight of for-
comprehensions, the convention of using apply, the insistence on using API-
leaking side effects for error handling (read: throwing exceptions), makes me
weep. Spark is a Java project maintained by a company filled with Java
engineers.

