Foreword

I often find myself, both professionaly and otherwise, having to explain bits of Scala to newcomers to the language (but usually not new to programming).

Something that’s becoming increasingly obvious is that Scala developers follow a certain set of unspoken rules without really thinking about them, and never really explain them to beginners. This is not helping Scala’s reputation as a hard to learn language, which is unfortunate - it’s a language I enjoy and wish more people would learn.

This site is meant to address that, by listing and explaining all these rules I wish someone’d told me about when I was learning the language.

Comments, suggestions, … are welcome! I’m clearly not the best Scala developer out there and might have gotten things wrong, or right for the wrong reasons. If you see areas that could be improved on, feel free to open an issue!

Table of Contents

Warming up

• Compare remainder to 0 when checking for oddness
• Use isNaN when checking for NaN
• Use upper case numeric literal suffixes

Tricky behaviours

• Add explicit type annotations to implicits
• Avoid unicode versions of ASCII operators
• Do not concatenate Strings with +
• Make implicit names as unique as possible
• Make subtypes of sealed types final
• Mark case classes as final
• Start independent Futures outside of a for-comprehension

Unsafe patterns

• Avoid implicit conversions
• Avoid structural types
• Do not compare arrays with ==
• Do not compute the size of a collection to check for emptiness
• Do not return Option from custom extractors
• Do not use null
• Make recursive functions tail-recursive
• Mark tail-recursive functions as such

Partial functions

• Avoid using head
• Avoid using init
• Avoid using last
• Avoid using reduce
• Avoid using tail
• Do not call get on an Either projection
• Do not call get on an Option
• Do not call get on an Try

Binary compatibility

• Add explicit type annotations to public members
• Prefer abstract classes to traits

Referential transparency

• Avoid mutability
• Do not throw exceptions
• Do not use return

ADTs

• Declare ADT data constructors in the companion object
• Make ADTs subtypes of Product and Serializable
• Make error ADTs subtypes of Exception
• Mark case objects as final
• Use ADTs to implement enumerations

OOP

• Declare abstract fields as paren-less methods
• Use override when implementing abstract members