Questions:
• What are the current Scala code styles?
• Are we respecting them? An analysis of Scala Open Source projects using Codacy
• What might become best practices/standard?
13. 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)
14.
15. 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
16.
17. Major differences
• Adds more than 40 rules to original style guide
• Introduces Collections, Object Oriented and Functional
style advice
• Shows preferences over APIs
18. 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
20. 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
24. 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)
25. Breakdown
Curly braces
Line max
Method naming
catching Fatal exceptions
Mutable fields
object naming convention
class naming convention
others
26. Other interesting facts
• Significant violations of Option.get
• Significant violations of nulls
27. Limitations of analysis
• Most popular tend to be libraries
• May not represent reality in industry perfectly
28. 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.
32. Collapsing of containers
Options
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)
Vs
Seq(startField.getOrElse("foo"),endField.getOrElse("bar"))
33. Collapsing of containers
Futures
Await.result(client.hGet(foo, bar)).get
Vs
client.hGet(foo, bar).map(f => ..)
34. Collections: optimizations
From Scapegoat
• 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
35. Akka
Guidelines
• Immutable messages
• If state becomes complex, context.become
• Not expose any state to outside
36. Unit testing
Testing with state
• Consistency in tests
• Encapsulate test state in a Context object.
37.
38. 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
39. 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)
40. Note: Microservices
• Style of thinking and code in ‘Your Server as a
Function’
• Server operations through future combinators
• Declarative programming