This blog on Scala code style is based on a presentation done on ScalaBay
Introduction
One of the reasons I am fascinated with Scala is the combination of bleeding edge experimentation, performance computation and reactiveness and big adoption by a growing list of companies1.
It’s rare to see programming languages cross the chasm of adoption while still be adventurous enough to push for modern programming language features.
It’s not by chance that people have started identifying similiarities between recent big programming language launches such as Swift 2345.
Spark is currently seeing a hockey stick-like growth which is also pushing Scala adoption.
To me personally, the most interesting aspects to Scala are the code styles.
Scala is a powerful language due (not only) to its extensive feature list and flexibility.
Because of this, it’s very important to define a coherent code style for each project/company so that people work together.
I wanted to study how each code style that I found deviated or added to the official and core code style.
Code styles
Without too much introduction, here’s a visualization of all code styles that are publicly available today:
https://dl.dropboxusercontent.com/u/3509093/Vis/index.html
quick guide
Center circles represent code styles.
Outer sentences represent their rules.
Circles in front of sentences mean their usage: bigger circles => more usage
I’ve explored each code style described below.
For each code style we extracted all the rules and listed them.
We then proceeded to match these rules and created a visualization to help understand how they overlap and what these code styles have in common.
We see that they mostly expand from the core official Scala style guide.
The biggest contributor to new rules is Effective Scala.
Official Scala code style
The official Scala code style was created by the Scala community and later adopted by the language docs.
It was originally created by Daniel Spiewak and David Copeland (1 2 3).
It’s permissive and flexible. There aren’t many “you shouldn’t do this”.
A couple of more firm stances include being careful with postfix operations, advice to prefer standard (or nominal) types over structural types, suggestion to avoid symbolic names method amongst others.
Overall it’s a great guide to follow. Very detailed and helpful.
You shouldn’t expect preference over APIs or any strong opinion over more functional tastes of Scala. This is a clean and dry style for you to have sane indentation, naming, general good use of the language, documentation and file organization.
I personally really like these guidelines as they serve as a baseline for more specific and rigid rules.
Effective Scala by Twitter
Effective Scala is an extensive guide.
It follows Twitter’s particular taste of Scala, including what APIs to use and features to overlook when writing Scala code.
Fundamentally, it started from the official scala style guide and has very few conflicting opinions.
It was written By Marius Eriksen
Overall, it’s a great read.
It has design principles applied to writing Scala code.
A very introductory selection of the guide includes:
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.
… And have fun.
It not only serves as a guideline for the rules developers at Twitter use to keep their code coherent, but also teaches you the most important techniques and features to use with example and case studies.
It goes further than to only explain code style; it actually presents good and bad design decisions you can make with Scala. It shows standard Twitter libraries you can use. It even has examples (complete with code snippets) you can use for your understanding.
It’s complete in rules, having from my count 116 rules to help you structure your code, abide by best practices and recommend not using certain features.
This is probably the most complete style guide to Scala to date (from what is publicly available).
Apache Spark
As said above, Spark which is growing in usage and adoption.
The code style is concise and to the point, having a lot in common with the core official Scala programming code style.
Here are the main differences:
- Max 100 character line
- Use 4 spaces for long arg lists
- Do not use relative imports from other packages
- Always use braces for ifs except for ternary operator behavior
- Do not use infix notation if method is not an operator (map, filter, flatMap)
The biggest help in the code style is a request to try to follow the style of the existing codebase.
I believe over time Spark will have more detailed rules as it’s starting the be the foundation of modern big data processing.
Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!
Conclusions
We’ve seen an analysis of the different code styles present today in the Scala community.
As we see the language growing, this will be an increasingly relevant topic.
Complete data
You can find the complete data set here.
- http://www.quora.com/What-startups-or-tech-companies-are-using-Scala ↩
- https://leverich.github.io/swiftislikescala/ ↩
- http://blog.ikiapps.com/post/97104339010/odersky-on-swift ↩
- http://java.dzone.com/articles/similarities-swift-scala ↩
- http://www.huffingtonpost.com/adam-denenberg/hello-swift-meet-scalab5453455.html ↩
- http://www.marketwired.com/press-release/survey-indicates-apache-spark-gaining-developer-adoption-as-big-datas-projects-require-1986162.htm ↩
- http://readwrite.com/2015/01/27/spark-scala-hadoop-typesafe-dean-wampler ↩
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.
