scala - 最佳实践(02) - 代码洁癖
代码洁癖
我们写代码给计算机运行，但是读代码的不仅仅是计算机，还有我们的战友（同事），还有未来的战友。
我们不能做一个猪队友，所以保证通用的代码规范是必要的。
每行代码需要有一个合理的长度
避免从左到右有很长的代码，当理解这行代码的时候会占用我们的思维。
在印刷制品中，最合理的长度在50-70个字符。
在编程过程中，我们使用缩进字符，60个字符太短了。
80字符通常是可以接受的，但不能用在Scala中，因为在Scala中我们使用了很多闭包函数和类的长名称和描述性名称，80字符太短了。
一种平衡的策略:
- 我们将80个字符作为基准。
- 一般不要超过100个字符。
- 如果可以的话将函数调用切换一行。
- 最好不要超过120个字符（IDEA默认提示120个字符）
不要依赖SBT或IDE插件来格式化代码
IDE会提供格式化插件，但使用的时候必须要小心。
IDE只是提供一个强制的规则，它并不能理解开发者的意图，简单的部分可以使用自动格式化。但还是尽量使用我们自己的逻辑添加格式。
一定要注意别调整他人已经仔细格式化好的代码！！
代码案例:
val dp = new DispatchPlan(new Set(filteredAssets), start = startDate, end = endDate, product, scheduleMap, availabilityMap, Set(activationIntervals.get), contractRepository, priceRepository)
大多数情况下，自动格式化会有如下结果:
val dp = new DispatchPlan(Set(filteredAssets), start =
startDate, end = endDate, product, scheduleMap, availabilityMap,
Set(activationIntervals), contractRepository, priceRepository)上面的可读性并不好，我们可以有如下的格式:
val dp = new DispatchPlan(
Set(filteredAssets),
startDate,
endDate,
product,
scheduleMap,
availabilityMap,
Set(activationIntervals),
contractRepository,
priceRepository
)上面这个看上去好多了，但事实上，对于某些场景，我们需要断开一行：
val result = service.something(param1, param2, param3, param4).map(transform)
如下两个糟糕的写法：
// transform调用不爽
val result = service.something(
param1,
param2,
param3,
param4).map(transform)
// 打破的逻辑
val result = service.something(
param1,
param2,
param3,
param4
).map(transform)下面这个会好很多:
val result = service
.something(param1, param2, param3, param4)
.map(transform)现在好多了，不是吗?当然，有时候这行太长了，您需要求助于某种临时值：
val result = {
val instance =
object.something(
myAwesomeParam1,
otherParam2,
someSeriousParam3,
anEvenMoreSoParam4,
lonelyParam5,
catchSomeFn6,
startDate7
)
for (x <- instance) yield
transform(x)
}- 当然，有时如果代码非常糟糕，就需要进行重构，比如，对于一个函数来说，参数太多。
- 所以我们严格控制每行代码的长度，避免使用自动格式化插件，会产生很多可读性的问题。
避免使用过长的函数
理想的函数应该只有几行。如果行太长，我们就需要把它们分解成更小的函数并给它们命名。
注意，在Scala中，我们不需要在其他范围中提供这样的中间函数，这里的目的主要是帮助可读性，所以在Scala中，我们可以使用内部函数将逻辑分解为多个部分。
避免错别字
多留意下划线提示吧！ 避免英文拼写错误，和中文注释错别字等等。
声明有意义的名称
*“在计算机科学中只有两件难事:缓存失效和命名。” -- Phil Karlton
这里我们有三条指导原则:
- 给出描述性的名称，但不要太过分，四个单词已经有点太多了
- 如果类型/用途可以从直接上下文轻松推断出来，或者已经建立了一种约定，那么可以简洁地命名
- 如果是描述性的，不要说无意义的废话
如下这个例子是可以接受的:我们可以从语境中直接看出p是一people，所以一个简短的字母名就可以了。
for (p <- people) yield transformed(p)
如下这个例子是可以接受的:因为“i”是作为索引使用的一种惯例
for (i <- 0 until limit) yield ???
如下这通常是不可接受的，因为通常使用元组时，集合的命名不能很好地反映所包含的内容(如果没有为这些元素命名，那么集合本身就会有不好的名称):
someCollection.map(_._2)
如下隐式参数对于短名称来说是可以接受的，因为隐式传递时，我们并不关心它们，除非它们丢失了:
def query(id: Long)(implicit ec: ExecutionContext, c: WSClient): Future[Response]
这是不可接受的，因为这个名称完全没有意义，即使有明确的描述性尝试:
def processItems(people: Seq[Person]) = ???
这是不可接受的，因为这个函数的命名表明了一个副作用(“process”是一个动词，表示一个命令)，但是它并没有描述我们对这些“人”所做的事情。“Items”后缀是没有意义的，因为我们可能会说“processThingy”、“processRows”、“processStuff”，但它仍然会说完全相同的东西——绝对没有。它还增加了视觉上的混乱，因为更多的单词就是更多的文本，而无意义的单词只是噪音