Databricks Scala Style Guide

The monadic chaining section makes no mention of for-yield strangely enough. Their example<p><pre><code> def getAddress(name: String): Option[String] = { database.get(name).flatMap { elem =&gt; elem.data.get(&quot;address&quot;) .flatMap(Option.apply) &#x2F;&#x2F; handle null value } } </code></pre> could just be<p><pre><code> def getAddress(name: String): Option[String] = { for { elem &lt;- database.get(name) address &lt;- elem.data.get(&quot;address&quot;) } yield address } </code></pre> and it&#x27;s way more readable than their given rewrite.<p>Then again, for-yield might be too magical and &quot;can confuse programmers less familiar with Scala,&quot; which seems to be a reason for a lot of the stylistic decisions.

This style guide discourages multiple parameter lists, but it doesn&#x27;t mention that they are useful for helping the compiler with type inference, as mentioned here: <a href="http://docs.scala-lang.org/style/declarations.html" rel="nofollow">http:&#x2F;&#x2F;docs.scala-lang.org&#x2F;style&#x2F;declarations.html</a> (granted, this is a bit of Scala ugliness, but it merits discussion).<p>I agree with several of their recommendations, but I strongly disagree with their general philosophy of &quot;[feature] can confuse programmers less familiar with Scala&quot;. It&#x27;s one thing for [feature] to be genuinely confusing, and an entirely different thing for it to be &quot;confusing to novices &#x2F; Java programmers&quot;. In the latter case, the right course of action is to educate them; otherwise we&#x27;d be stuck programming in Java++.

So far it&#x27;s the best style guide I&#x27;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 (+ - &#x2F; * etc...) I really hate all the ~&gt; &lt;|-|&gt; &lt;:&lt; madness, it gives Scala a really bad name.<p>I like it how they prefer JAVA_STYLE_CONSTANTS over ScalaStyleConstants and same thing for annotations.<p>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.<p>Great style guide. I&#x27;m adopting it. It&#x27;s strict on one way, but let&#x27;s you escape if you have a reason.<p>The only caveat is what others have mentioned regarding monadic chaining. I prefer to use for-yield when it&#x27;s clear that I&#x27;m working with collection transformations, nested futures, and even nested options. only when it&#x27;s too cumbersome to read I break it down to the desugared form.

Do any of you know if there is an equivalent of gofmt for scala, e.g scalafmt?<p>If such a thing existed some portion of this long list of sensible conventions wouldn&#x27;t have to be memorized and&#x2F;or constantly referenced and manually enforced.<p>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.

It&#x27;d be overkill to submit a PR for this so: it should be &quot;to the best OF our knowledge&quot; in the first line.<p>I wish organisations would provide IntelliJ configuration files (or similar) when releasing such style guides as well... ;)

Lots of good sense, but a few things make the code clunkier than scala needs to be IMO.<p><pre><code> try foo catch {...} </code></pre> is readable and consistent; the idea that {} <i>just makes a block</i> is really useful, making try&#x2F;catch, if&#x2F;then and even method definitions a lot less &quot;magic&quot;, a lot less cluttered by ceremony.<p>Infix method calls can likewise read much more clearly:<p><pre><code> string contains &quot;foo&quot; </code></pre> Try is bad, but \&#x2F; makes a better alternative to throwing an exception for exactly the same reasons that Option is better than returning null.

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!

This style guide is depressing... The author&#x27;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.