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) - 代码洁癖的主要内容,如果未能解决你的问题,请参考以下文章

在 Scala 注释中使用常量的最佳实践

scala - 最佳实践(03):Method名称

Perl 最佳实践(节选) --- 02

在 Elasticbeanstalk for Scala Apps 中为 Docker 多容器环境部署和托管工件的最佳实践是啥?

什么是分析和性能测试 python 代码的最佳实践和工具? [复制]

将 Play 代码从 git 存储库部署到生产环境的最佳实践是啥?