scala - 最佳实践(02) - 代码洁癖
Posted duchaoqun
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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”,但它仍然会说完全相同的东西——绝对没有。它还增加了视觉上的混乱,因为更多的单词就是更多的文本,而无意义的单词只是噪音
以上是关于scala - 最佳实践(02) - 代码洁癖的主要内容,如果未能解决你的问题,请参考以下文章
在 Elasticbeanstalk for Scala Apps 中为 Docker 多容器环境部署和托管工件的最佳实践是啥?