Scala <\/a>is one of the main application programming languages used at Twitter. Much of our infrastructure is written in Scala and we have several large libraries<\/a>\u00a0supporting our use. While highly effective, Scala is also a large language, and our experiences have taught us to practice great care in its application. What are its pitfalls? Which features do we embrace, which do we eschew? When do we employ \u201cpurely functional style\u201d, and when do we avoid it? In other words: what have we found to be an effective use of the language? This guide attempts to distill our experience into short essays, providing a set of\u00a0best practices<\/em>. Our use of Scala is mainly for creating high volume services that form distributed systems \u2014 and our advice is thus biased \u2014 but most of the advice herein should translate naturally to other domains. This is not the law, but deviation should be well justified.<\/p>\n Scala provides many tools that enable succinct expression. Less typing is less reading, and less reading is often faster reading, and thus brevity enhances clarity. However brevity is a blunt tool that can also deliver the opposite effect: After correctness, think always of the reader.<\/p>\n Above all,\u00a0program in Scala<\/em>. You are not writing Java<\/a>, nor Haskell<\/a>, nor Python<\/a>; a Scala program is unlike one written in any of these. In order to use the language effectively, you must phrase your problems in its terms. There\u2019s no use coercing a Java program into Scala, for it will be inferior in most ways to its original.<\/p>\n This is not an introduction to Scala; we assume the reader is familiar with the language. Some resources for learning Scala are:<\/p>\n This is a living document that will change to reflect our current \u201cbest practices,\u201d but its core ideas are unlikely to change: Always favor readability; write generic code but not at the expensive of clarity; take advantage of simple language features that afford great power but avoid the esoteric ones (especially in the type system). Above all, be always aware of the trade offs you make. A sophisticated language requires a complex implementation, and complexity begets complexity: of reasoning, of semantics, of interaction between features, and of the understanding of your collaborators. Thus complexity is the tax of sophistication \u2014 you must always ensure that its utility exceeds its cost.<\/p>\n And have fun.<\/p>\n The specifics of code\u00a0formatting<\/em>\u00a0\u2014 so long as they are practical \u2014 are of little consequence. By definition style cannot be inherently good or bad and almost everybody differs in personal preference. However the\u00a0consistent<\/em>\u00a0application of the same formatting rules will almost always enhance readability. A reader already familiar with a particular style does not have to grasp yet another set of local conventions, or decipher yet another corner of the language grammar.<\/p>\n This is of particular importance to Scala, as its grammar has a high degree of overlap. One telling example is method invocation: Methods can be invoked with \u201c <\/a>We adhere to the\u00a0Scala style guide<\/a>\u00a0plus the following rules.<\/p>\n Indent by two spaces. Try to avoid lines greater than 100 columns in length. Use one blank line between method, class, and object definitions.<\/p>\n to<\/p>\n They are redundant in use:\u00a0 in favor of the unambiguous<\/p>\n\n
Formatting<\/h2>\n
.<\/code>\u201d, with whitespace, without parenthesis for nullary or unary methods, with parenthesis for these, and so on. Furthermore, the different styles of method invocations expose different ambiguities in its grammar! Surely the consistent application of a carefully chosen set of formatting rules will resolve a great deal of ambiguity for both man and machine.<\/p>\nWhitespace<\/h3>\n
Naming<\/h3>\n
\n
i<\/code>s,\u00a0j<\/code>s and\u00a0k<\/code>s are all but expected in loops.<\/dd>\nFuture.collect<\/code>\u00a0not\u00a0Future.all<\/code>.<\/dd>\nok<\/code>,\u00a0err<\/code>\u00a0or\u00a0defn<\/code>\u00a0whereas\u00a0sfri<\/code>\u00a0is not so common.<\/dd>\nval<\/code>s<\/dd>\n`<\/code>s to overload reserved names.<\/dt>\ntyp<\/code>\u00a0instead of\u00a0`type<\/code>`<\/dd>\nuser.activate()<\/code>\u00a0not\u00a0user.setActive()<\/code><\/dd>\nsrc.isDefined<\/code>\u00a0not\u00a0src.defined<\/code><\/dd>\nget<\/code><\/dt>\nsite.count<\/code>\u00a0not\u00a0site.getCount<\/code><\/dd>\nobject User {\r\n def get(id: Int): Option[User]\r\n}<\/code><\/pre>\nobject User {\r\n def getUser(id: Int): Option[User]\r\n}<\/code><\/pre>\nUser.getUser<\/code>\u00a0provides no more information than\u00a0User.get<\/code>.<\/dd>\n<\/dl>\nImports<\/h3>\n
\n
import com.twitter.concurrent.{Broker, Offer}<\/code><\/dd>\nimport com.twitter.concurrent._<\/code>
\nDon’t apply this blindly: some packages export too many names<\/dd>\nscala.collection.immutable<\/code>\u00a0and\/or\u00a0scala.collection.mutable<\/code><\/dt>\nimmutable.Map<\/code>“)<\/dd>\nimport com.twitter\r\nimport concurrent<\/code><\/pre>\nimport com.twitter.concurrent<\/code><\/pre>\n<\/dd>\n