Название: Scala Best Practices: Write Clean and Robust Code Автор: Hirako San
Издательство: Amazon Digital Services LLC
Год: 2018
Язык: английский
Формат: epub, rtf, pdf (conv)
Размер: 10.1 MB
A collection of best practices to write clean and robust Scala code. This manual contains curated best practices and recipes.
What's inside:
- Hygienic Rules on code formatting
- Language Rules
- Architecture
- Concurrency and Parallelism
- Actors
MUST NOT use "return"
The return statement from Java signals a side-effect - unwind the stack and give this value to the caller. In a language in which the emphasis is on side-effect-full programming, this makes sense. However, Scala is an expression oriented language in which the emphasis is on controlling/limiting side-effects and return is not idiomatic. To make matters worse, return probably doesn't behave as you think it does.
SHOULD NOT define useless traits
There was this Java Best Practice that said "program to an interface, not to an implementation", a best practice that has been cargo-cult-ed to the point that people started defining completely useless interfaces in their code. Generally speaking, that rule is healthy, but it refers to the general engineering need of hiding implementation details; especially details of modifying state (encapsulation) and not to slap interface declarations that often leak implementation details anyway. Defining traits is also a burden for readers of that code, because it signals a need for polymorphism.
SHOULD avoid concurrency like the plague it is
Avoid having to deal with concurrency as much as possible. People good at concurrency avoid it like the plague it is.
WARNING: concurrency issues happen not only when speaking about shared memory and threads, but also between processes when contention on any kind of resource (like a database) is involved. Example - when a job is scheduled to execute every minute by using cron.d in Linux and that job fetches and updates items from a queue persisted in MySQL, that job can take longer than 1 minute to execute and thus you can end up with 2 or 3 processes executing at the same time and contending on the same MySQL table.
SHOULD use appropriate abstractions only where suitable - Future, Actors, Rx
Learn about the abstractions available and choose between them depending on the task at hand. There is no silver bullet that can be generally applied. The more high-level the abstraction, the less scope it has in solving issues. But the less scope and power it has, the simpler and more composable the model is. For example many developers in the Scala community are overusing Akka Actors - which are great, but not when misapplied. Like don't use an Akka Actor when a Future would do.
Скачать Scala Best Practices: Write Clean and Robust Code