State of Scala code style

Hello!

• Jaime Jorge from Codacy

• Master thesis & company with Scala

• Scala lover for 4 years

• Why?

• Questions

• Code styles

• OSS Analysis

• Brief overview of observations

Why care?

• Expressive language, haters like to call ‘complex’

• We’re reviewing code everyday

• Reduce number of moving parts

• Onboarding becomes easier

Questions

• What are the current code styles?

• Are we respecting them?

• What might become best practices/standard?

What code styles are currently out there?

Gathered code styles• Official Scala Style

• Twitters Effective Scala

• Apache Spark

• Bizo Scala Style

• Kiji project

• Vertx mod lang

• Apache Kafka

Method

• Categories

• Extract rules from all

• Understand what they have in common/different

Rules extracted

• 127 rules total

• All taken from guidelines

Major differences

• Max 100 character line

• 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)

Major differences• Max 80 character line

• Declarations:

• Use vals when possible.

• Use private when possible for member variables.

• Use named arguments when passing in literal values

• Options should be used instead of null whenever possible

• Prefer case classes over tuples

Major differences

• Adds more than 40 rules to original style guide

• Introduces Collections, Object Oriented and Functional style advice

• Shows preferences over APIs

Conclusion

• Built upon Scala Style Guide

• 127 rules you can choose for your project

• Some differences are important enough to include in Official Scala Style

Are we respecting them?

Answer by

• Analyzing open source projects for violations of Official Scala Style

• Understand % of compliance

• Understand number of code style violations

• Per category

• Per code pattern

OSS Analysis

• Analyzed 50 most popular Scala projects

Tools

• ScalaStyle

• HairyFotr/linter

• WartRemover

• Abide

• scapegoat

• Codacy

Results

• 51% code style compliance on average

• Inverse correlation between Age of project and Code style compliance of project

• Correlation between number of committers and number of violations (expected)

BreakdownCurly braces

Line max

Method naming

catching Fatal exceptions

Mutable fields

object naming convention

class naming convention

others

Other interesting facts

• Significant violations of Option.get

• Significant violations of nulls

Limitations of analysis

• Most popular tend to be libraries

• May not represent reality in industry perfectly

Conclusions

• 51% code style compliance on average

• Naming and formatting biggest culprits

• Older projects have less compliance

• Are we respecting them?

• Answer: we could do a better job.

What might become standard?

Areas

• Collection of rules we see enforced humanly in Pull requests and commits

Areas

• Collections

• Testing

• Object oriented programming

• Functional programming

Collapsing of containersOptions

if (startField.isEmpty && endField.isEmpty) Seq("foo", "bar")else if (startField.isEmpty && !endField.isEmpty) Seq("foo", endField.get)else if (!startField.isEmpty && endField.isEmpty) Seq(startField.get, "bar") else Seq(startField.get, endField.get)

Seq(startField.getOrElse("foo"),endField.getOrElse("bar"))

Vs

Collapsing of containers

Await.result(client.hGet(foo, bar)).get

client.hGet(foo, bar).map(f => ..)

Vs

Futures

Collections: optimizations• exists(x => x == b) replaceable with contains(b)

• .filter(x => ).head can be replaced with find(x => ) match { .. }

• .filter(x =>).headOption can be replaced with find(x => )

• .filter(x => Bool).isEmpty can be replaced with !exists(x => Bool)

• .filter(_.isDefined).map(_.get) can be replaced with flatten

• .filter(x => Bool).size can be replaced more concisely with with count(x => Bool)

• sort.filter can be replaced with filter.sort for performance

• !Traversable.isEmpty can be replaced with Traversable.nonEmpty

• !Traversable.nonEmpty can be replaced with Traversable.isEmpty

From Scapegoat

Akka

• Immutable messages

• If state becomes complex, context.become

• Not expose any state to outside

Guidelines

Unit testing

• Consistency in tests

• Encapsulate test state in a Context object.

Testing with state

Object oriented programming

• Use dependency injection for program modularization

• The use of traits are highly encouraged

• Do not use Exceptions for commonplace errors

• Encode commonplace errors explicitly: using Option or (scala.util./com.twitter.util.)Try

Functional programming• Options should be used instead of null whenever

possible

• Do not overuse Option: if there is a sensible default — a Null Object — use that instead.

• Don’t use pattern matching for conditional execution

• Only use call-by-name for creating new control constructs such as DSLs

• Prefer case classes over tuples (specially no ._1)

Note: Microservices

• Style of thinking and code in ‘Your Server as a Function’

• Server operations through future combinators

• Declarative programming

Microservices: declarative programming

recordHandletime andThentraceRequest andThencollectJvmStats andThenparseRequest andThenlogRequest andThenrecordClientStats andThensanitize andThenrespondToHealthCheck andThenapplyTrafficControl andThenvirtualHostServer

Thanks! QA

Exclusive Offer

Use Codacy for free for 3 months on private repositories

Promo Code: SCALABAY-LLHLKS