Scala provides a lot of high-powered tools and libraries for ensuring correctness at compile-time. However, these can often be either intimidating for new Scala developers or just don't fit the style of a certain codebase. Often though there's a lot of low-hanging fruit when it comes to structuring your type signatures that can offer big dividends when it comes time to refactor and are accessible for any newcomer to your codebase.
I'll go over a list of simple, but potentially non-obvious, guidelines to help with correct sequencing of data transformation steps, self-documenting pre- and post-conditions in the types, and more, as well as common mistakes to be avoided. For example:
- Classic defensive programming techniques are probably a code smell when it comes to types
- Total functions are good, total + surjective is better (don't know what surjective is? I'll tell you in the talk :))
- And more!
These guidelines as well as the reasoning behind them that apply to both Scala written in a more OO-FP hybrid style as well as Scala written in a more pure FP style. They serve as a demonstration that it doesn't take a lot of fancy bells and whistles to get meaningful mileage out of your type system and as a field report of what's paid off (and what hasn't) over the lifetime of a Scala-heavy tech team.