scalaのベストプラクティス（02）-コードの清浄度

コードの清浄度

コンピューターを実行するためのコードを作成しますが、コードを読み取るのはコンピューターだけではなく、仲間（同僚）や将来の仲間もです。
私たちは豚のチームメイトになることはできないため、共通のコード仕様を保証する必要があります。

コードの各行は、適切な長さである必要があります

このコード行を理解することは私たちの思考の中心となるので、左から右に長いコードを持つことは避けてください。

印刷物では、最も適切な長さは50〜70文字です。

プログラミングプロセスでは、インデントされた文字を使用しています。60文字は短すぎます。
80文字は一般に許容されますが、Scalaでは使用できません。Scalaでは、クロージャー関数とクラスの長くてわかりやすい名前を多く使用しているため、80文字は短すぎるためです。

バランスの取れた戦略：

ベンチマークとして80文字を使用します。
通常は100文字以下です。
可能であれば、関数呼び出しを1行に切り替えます。
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)

次の2つの不適切な書き込み方法：

    // 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では、内部関数を使用してロジックを複数の部分に分割できます。

タイプミスを避ける

下線のヒントにもっと注意してください！英語のスペルミス、中国語の注釈のタイプミスなどを回避します。

意味のある名前を宣言する

*「コンピュータサイエンスには、キャッシュの無効化と命名の2つの難しいことしかありません。」-Phil Karlton

ここには、3つの指針があります。

説明的な名前を付けますが、あまり遠くに行かないでください。4つの単語はすでに少し多すぎます
タイプ/用途が直接のコンテキストから簡単に推測できる場合、または規約が確立されている場合は、簡潔に名前を付けることができます
説明的である場合は、無意味なナンセンスを話さないでください

次の例は許容されます。pは人であることをコンテキストから直接確認できるため、短い文字の名前で十分です。

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]) = ???

この関数の名前は副作用（「プロセス」は動詞、つまりコマンドを意味します）を示すため、これは受け入れられませんが、これらの「人」に対して何を行うかを説明していません。「Items」接尾辞は意味がないため、「processThingy」、「processRows」、「processStuff」と言うこともありますが、まったく同じことは何も言うことはありません。また、多くの単語はより多くのテキストであり、無意味な単語は単なるノイズであるため、視覚的な混乱も追加します