swift-format 全設定の解説：どの項目が何を変えるのか

lineLength#

1行の最大文字数。これを超えると改行の処理が入る。

1
// lineLength: 80
2
let view = makeRow(title: "Title", subtitle: "Subtitle", icon: iconName, action: handler)
3
let view = makeRow(
4
  title: "Title", subtitle: "Subtitle", icon: iconName, action: handler)

選んだ値：100（デフォルト）。 Swiftは型名も引数ラベルも元々長く、80だとSwiftUIのview部分が細切れになる。100はGoogle Swift Style Guideの値であり、swift-format自身のデフォルトでもある。

indentation#

1段のインデントを何で作るか。{"spaces": N}か{"tabs": N}を書く。

1
struct Point {
2
  var x: Int
3
  func move() {
4
    x += 1
5
  }
6
    var x: Int
7
    func move() {
8
        x += 1
9
    }
10
}

選んだ値：{"spaces": 4}。 swift-formatのデフォルトは2スペースだが、Xcodeのエディタ既定値は4スペースで、Appleのサンプルコードも4である。Xcodeで手で打ったインデントとフォーマット後のインデントが食い違うのは避けたい。

tabWidth#

この名前は誤解を招く。「インデント幅」ではなく、行の長さを測るときにタブ1文字を何桁として数えるかである。

indentationがスペースなら、この値は出力にまったく影響しない。タブでインデントしている場合にだけ差が出る。以下は同じコード、同じlineLength: 60、同じタブインデントで、tabWidthだけが違う。

1
// tabWidth: 8 —— タブ2段が16桁と数えられ、残りが足りず改行される
2
func outer() {
3
  func inner() {
4
    let r = compute(
5
      alpha: 1, beta: 2, gamma: 3,
6
      delta: 44)
7
  }
8
}
9

10
// tabWidth: 4 —— タブ2段は8桁なので1行に収まる
11
func outer() {
12
  func inner() {
13
    let r = compute(alpha: 1, beta: 2, gamma: 3, delta: 44)
14
  }
15
}

選んだ値：4。ただし正直なところ、自分の設定では効いていない。 スペースでインデントしているので、swift-formatが幅を換算すべきタブに出会うことがない。エディタの設定と揃えるために残しているだけで、消しても結果は変わらない。

indentBlankLines#

空行に現在の段のインデントを入れるか（つまり行末に空白を残すか）。

1
func f() {
2
    let a = 1
3

4
    ⎵⎵⎵⎵
5
    let b = 2
6
}

（上の⎵は実際に生成される空白である。）

選んだ値：false（デフォルト）。 有効にすると行末空白ができ、多くのエディタの「保存時に行末空白を削除」やgit diffの読み方と衝突する。

maximumBlankLines#

連続する空行を何行まで許すか。それ以上は畳まれる。

1
let a = 1
2

3

4
let b = 2

（上は2からデフォルトの1に戻したときの効果。）

選んだ値：1（デフォルト）。 空行で論理的な塊を分けはするが、「より大きな区切り」を表すために2行以上を使う必要はない。それは見出しコメントの仕事である。

spacesBeforeEndOfLineComments#

行末の//コメントの前に空白をいくつ置くか。

1
let a = 1  // one
2
let bb = 22  // two
3
let a = 1 // one
4
let bb = 22 // two

（上は1にしたときの効果。）揃えはしない。固定個数の空白を保証するだけである。

選んだ値：2（デフォルト）。 1個だとコメントがコードに近すぎる。2個あれば視覚的に離れる。

spacesAroundRangeFormationOperators#

...と..<の前後に空白を入れるか。

1
let r = 0..<10
2
let c = 1...5
3
let r = 0 ..< 10
4
let c = 1 ... 5

選んだ値：false（デフォルト）。 0..<10は一つのまとまりとして読んでいる。空白を入れると3つの独立した語のように見える。

indentConditionalCompilationBlocks#

#if / #endifの中身をもう1段インデントするか。

1
func f() {
2
  #if DEBUG
3
  let a = 1
4
  print(a)
5
    let a = 1
6
    print(a)
7
  #endif
8
}

（デフォルトのtrueが右側。）

選んだ値：true（デフォルト）。 #ifは開きと閉じを持つ構造なので、中身を1段下げるのは直感に合う。

indentSwitchCaseLabels#

caseをswitchに対してインデントするか。

1
switch v {
2
case 1:
3
  print(1)
4
default:
5
  break
6
  case 1:
7
    print(1)
8
  default:
9
    break
10
}

選んだ値：false（デフォルト）。 Swiftコミュニティの主流であり、Appleのドキュメントもこの形である。有効にするとswitch全体が2段右に寄り、すでにネストしたコードでは場所を取りすぎる。

respectsExistingLineBreaks#

手で書いた改行を尊重するかどうか。

1
let a = compute(
2
  x: 1,
3
  y: 2
4
)
5
let a = compute(x: 1, y: 2)
6
let b = 1 + 2

（上はfalseにしたときの効果。結合できるものはすべて結合される。）

選んだ値：true（デフォルト）。 ファイル中で最も重要な項目だと思っている。これを切るとswift-formatは「行の密度を最大化する機械」になり、グループを表現するために手で分けた引数リストが容赦なく1行にまとめられる。有効なら、ルールに違反しない限り手書きの改行は残る。フォーマッタは下限を担保し、表現は人が持つ。

lineBreakBeforeEachArgument#

引数リストが1行に収まらないとき、各行をできるだけ詰めるか、1引数につき1行にするか。

1
let view = makeRow(
2
  title: "Title", subtitle: "Subtitle", icon: iconName, action: handler, isEnabled: true)
3
  title: "Title",
4
  subtitle: "Subtitle",
5
  icon: iconName,
6
  action: handler,
7
  isEnabled: true
8
)

関数宣言も同じである。

1
func makeRow(
2
  title: String, subtitle: String, iconName: String, action: @escaping () -> Void, isEnabled: Bool,
3
  title: String,
4
  subtitle: String,
5
  iconName: String,
6
  action: @escaping () -> Void,
7
  isEnabled: Bool,
8
  badgeCount: Int
9
) -> Row {

選んだ値：true。 デフォルトの詰め込み方式には実用上の問題がある。引数を1つ足すと後ろの引数がすべて並び替わり、実際は1つ追加しただけなのにdiffでは5行変わったように見える。1引数1行なら、引数の追加は行の追加で済む。SwiftUIのイニシャライザは引数が多く長いので、この差はコードレビューではっきり出る。

代償は縦に長くなること。それは受け入れる。

lineBreakBeforeEachGenericRequirement#

同じ考え方をwhere句に適用したもの。

1
func merge<A, B>(_ a: A, _ b: B) -> [A.Element]
2
where
3
  A: Sequence, B: Sequence, A.Element == B.Element, A.Element: Hashable, B.Element: Comparable,
4
  A: Codable, B: Codable, A: Sendable
5
  A: Sequence,
6
  B: Sequence,
7
  A.Element == B.Element,
8
  A.Element: Hashable,
9
  B.Element: Comparable,
10
  A: Codable,
11
  B: Codable,
12
  A: Sendable
13
{

where句が折り返しを要する長さになったときだけ働く。短いものは影響を受けない。

選んだ値：true。 前の項目と同じ理由で揃えた。実際には自分のプロジェクトにはまだ折り返すほど長いwhere句がないので、今のところ将来のために書いてある。

lineBreakBeforeControlFlowKeywords#

elseやcatchのようなキーワードを行頭に置くか。

1
  if condition {
2
    print(a)
3
  } else {
4
  }
5
  else {
6
    print(0)
7
  }
8
}

選んだ値：false（デフォルト）。 } else {はSwiftで広く使われる書き方であり、Allmanスタイルに変えるとどのSwiftプロジェクトでも浮く。

lineBreakBetweenDeclarationAttributes#

複数の属性をそれぞれ1行にするか。

1
@MainActor @preconcurrency final class Store {
2
@MainActor
3
@preconcurrency
4
final class Store {
5
  var value = 0
6
}

選んだ値：false（デフォルト）。 SwiftUIでは@State private varのような組み合わせが多く、強制的に分けるとプロパティ宣言の領域が縦一列になる。しかもこの項目は全体に効くので、「長い属性のときだけ」という指定はできない。

lineBreakAroundMultilineExpressionChainComponents#

メソッドチェーンが収まらないとき、メソッド名の間で折るか、引数の括弧の中で折るか。

1
let names = people.filter { $0.age > 18 }.map { $0.name.uppercased() }.sorted().joined(
2
  separator: ", ")
3
let names = people.filter { $0.age > 18 }.map { $0.name.uppercased() }.sorted()
4
  .joined(separator: ", ")

選んだ値：false（デフォルト）。 これは迷った。有効にすると折る位置が意味的に自然になる（.で折れる）が、実際の挙動は「複数行のチェーンの各要素の前後で強制的に改行する」なので、あるチェーンが複数行と判定された時点で全体がばらける。デフォルトの出力で自分のコードには足りているので、今は触らない。

prioritizeKeepingFunctionOutputTogether#

関数シグネチャが収まらないとき、どの部分を守るか。この記事で一番気に入っている項目である。

1
func loadConfiguration(from url: URL, using decoder: JSONDecoder, strict: Bool) throws
2
  -> Configuration
3
{
4
func loadConfiguration(
5
  from url: URL, using decoder: JSONDecoder, strict: Bool
6
) throws -> Configuration {
7
  try decoder.decode(Configuration.self, from: Data(contentsOf: url))
8
}

デフォルト（false）は戻り値の型を次の行へ送り、シグネチャが複数行になった結果、開き波括弧まで単独行に追いやられる。シグネチャ3行と孤立した{ができあがる。有効にすると引数リストのほうが分割され、) throws -> Configuration {はまとまったまま残る。

選んだ値：true。 戻り値の型は関数シグネチャの中でも情報量の多い部分で、引数リストから切り離す理由がない。孤立した{も、4スペースでインデントされたコードの中ではやけに目立つ。

multiElementCollectionTrailingCommas#

要素が複数ある配列・辞書リテラルで、最後の要素の後ろにカンマを置くか。

1
let colors = [
2
  "red",
3
  "green",
4
  "blue"
5
  "blue",
6
]

単一要素のコレクションは影響を受けない。["only"]を複数行に開いてもカンマは付かない。

選んだ値：true（デフォルト）。ただし自分の設定ではすでに効いていない。 理由は次の項目にある。

multilineTrailingCommaBehavior#

適用範囲がより広い。引数リスト、タプルなど「対称に区切られたカンマ区切りのリスト」すべてで、コレクションリテラルも含む。値は3つ。

• keptAsWritten（デフォルト）：書いてあれば残し、なければ足さない。コレクションリテラルは前の項目に任せる
• alwaysUsed：複数行のリストには必ず付ける
• neverUsed：すべて削除する

1
let view = makeRow(
2
  title: "Title",
3
  subtitle: "Subtitle",
4
  icon: iconName,
5
  icon: iconName
6
)

選んだ値：neverUsed。

最初はalwaysUsedにしていた。末尾カンマがあれば最後の要素も他の要素と同じように追加・削除・並び替えができ、引数を1つ足してもdiffは1行で済む、という理由である。この理由自体は間違っていないが、カバーできない範囲がある。名前のとおりmultilineTrailingCommaBehaviorは複数行のリストしか扱わない。1行のmakeRow(title: "a", subtitle: "b")にカンマが付くことは決してない。

つまりalwaysUsedで実際に得られるのは「複数行にはある、1行にはない」という分裂したルールである。同じ呼び出しが、100桁を超えたかどうかで書き方を変える。neverUsedなら一つのルールですべてを覆える。どこにも末尾カンマは付かない。それで後者に変えた。

代償はdiff上の利点を手放すこと。得られるのは「このリストは今1行なのか複数行なのか」を考えなくて済むことである。

2つの波及。

一つ目は、neverUsedがmultiElementCollectionTrailingCommasを上書きすること。後者がtrueのままでも、コレクションリテラルの末尾カンマは削除される。

1
// multiElementCollectionTrailingCommas: true + multilineTrailingCommaBehavior: neverUsed
2
let colors = [
3
    "red",
4
    "green",
5
    "blue"
6
]

つまりmultiElementCollectionTrailingCommasの行は、自分の設定では今は空回りしている。将来keptAsWrittenに戻すときに考え直さなくて済むよう残しているが、出力には一切影響しない。

二つ目は、コンパイラのバージョン要件が消えること。引数リストの末尾カンマはSE-0439で導入された構文で、Swift 6.1以降のコンパイラが必要である（実際に確かめたが、言語モードによる制限ではない。コンパイラさえ新しければ-swift-version 5でも通る）。alwaysUsedを選ぶと古いツールチェーンでビルドできないコードが生成される。neverUsedならこの問題は起きない。

ついでに一つバグ。 手書きの1行末尾カンマは構文上は正しい（makeRow(title: "a", subtitle: "b",)も[1, 2, 3,]もコンパイルできる）が、swift-formatの処理は綺麗ではない。neverUsedはカンマを削除した後に空白を残し、収束するには2回目の実行が必要になる。

1
// 入力
2
let v = makeRow(title: "a", subtitle: "b",)
3

4
// 1回目
5
let v = makeRow(title: "a", subtitle: "b" )
6

7
// 2回目
8
let v = makeRow(title: "a", subtitle: "b")

デフォルトのkeptAsWrittenはさらに悪く、("b", )をそのまま残し、何度実行しても変わらない。コレクションリテラルにこの問題はない。自分で1行の末尾カンマを打つことはあまりないだろうが、他のプロジェクトからコードを移してきた場合は、コミット前に2回フォーマットしておく価値がある。

reflowMultilineStringLiterals#

複数行文字列リテラルの中で、長すぎる行を\の継続で折り返すかどうか。

1
// never（デフォルト）
2
let message = """
3
  This line is short.
4
  This particular line is quite long and definitely goes past the configured maximum line length limit of one hundred columns.
5
  """
6

7
// onlyLinesOverLength
8
let message = """
9
  This line is short.
10
  This particular line is quite long and definitely goes past the configured maximum line length \
11
  limit of one hundred columns.
12
  """

3つ目の値alwaysの説明は「既存のエスケープ改行を無視して常に再整形する」である。試したいくつかの例ではonlyLinesOverLengthと同じ出力になった。短い行を結合することはない。違いが出るのは、すでに\の継続を含むリテラルだけだと思われる。

選んだ値：onlyLinesOverLength。 文字列リテラルだけが100桁を超えられる場所になるのは避けたい（それではlineLengthが形骸化する）が、行ごとに整えた短いテキストをフォーマッタに触られるのも困る。この中間の値がちょうどよい。

fileScopedDeclarationPrivacy#

ファイルスコープの非公開宣言をprivateとfileprivateのどちらに揃えるか。FileScopedDeclarationPrivacyルールに対応する。

1
fileprivate let cache = 1
2
fileprivate func helper() {}
3
private let cache = 1
4
private func helper() {}

ファイルスコープではこの2つのキーワードの意味は完全に同じなので、純粋に書き方を揃えるだけの設定である。

選んだ値：private（デフォルト）。 短く、型の内部で使うprivateと見た目が揃う。

noAssignmentInExpressions#

NoAssignmentInExpressionsルールの許可リスト。どの関数なら引数の中に代入を書いてよいか。

デフォルトは["XCTAssertNoThrow"]で、XCTAssertNoThrow(x = try compute())がテストでよくある書き方だからである。許可リストを空にすると、この行が報告される。

1
warning: [NoAssignmentInExpressions] move this assignment expression into its own statement

選んだ値：デフォルトの["XCTAssertNoThrow"]のまま。 自分のプロジェクトはXCTestではなくSwift Testingを使っているので、この許可リストは今のところ空回りしている。デフォルトを残しておくコストはない。

orderedImports#

OrderedImportsルールの2つのスイッチ。

shouldGroupImports（デフォルトtrue）：種類の違うimportをグループに分け、間に空行を入れる。

1
import Foundation
2
import UIKit
3

4
import enum Swift.Optional
5

6
@testable import MyApp
7
import UIKit

順序は、通常のimport → 単一シンボルのimport（import enum Swift.Optional）→ @testable importで、グループ内はアルファベット順。無効にするとすべて混ざり、アルファベット順のみになる。

includeConditionalImports（デフォルトfalse）：#ifブロック内のimportも並べ替えるか。

1
#if canImport(Combine)
2
  import Combine
3
  import Accelerate
4
  import Combine
5
#endif

選んだ値：どちらもデフォルトのまま（グループ化 = true、条件付き = false）。 グループ化されていれば@testableが一目で分かる。条件付きコンパイルブロック内のimportの順序には意味がある場合（依存関係など）があるので、ツールに触らせたくない。

AlwaysUseLiteralForEmptyCollectionInit（書き換える）#

1
var names = [String]()
2
var lookup = [String: Int]()
3
var names: [String] = []
4
var lookup: [String: Int] = [:]

有効にした理由： どちらの書き方も等価だが、後者は型を型の位置に書いている。宣言の左に型注釈、右に値という形はvar x: Int = 0と同じである。

BeginDocumentationCommentWithOneLineSummary（報告のみ）#

ドキュメントコメントの最初の文を、独立した1行の要約にすることを求める。

1
/// Returns the sum of two integers. This function is very simple. It adds them.
2
func add(_ a: Int, _ b: Int) -> Int { a + b }

1
warning: [BeginDocumentationCommentWithOneLineSummary]
2
add a blank comment line after this sentence: "Returns the sum of two integers."

有効にした理由： XcodeのQuick HelpもDocCも、最初の段落だけを要約として取る。3文の要約を書くと、Quick Helpに塊のまま表示される。

NeverForceUnwrap / NeverUseForceTry / NeverUseImplicitlyUnwrappedOptionals（いずれも報告のみ）#

1
warning: [NeverForceUnwrap] do not force unwrap 'Int(s!)'
2
warning: [NeverUseForceTry] do not use force try
3
warning: [NeverUseImplicitlyUnwrappedOptionals] use 'String' or 'String?' instead of 'String!'

有効にした理由： Atofolioは外部データを取り込むアーカイブアプリで、Bangumi、Steam、Apple Musicのフィールドはいつ欠けても形が変わってもおかしくない。プロジェクトの第一原則は「欠けている情報を捏造しない、不明は不明のまま残す」である。!はこの原則と最も直接的に衝突する構文で、「ここには値がないかもしれない」を「ここに値がなければクラッシュする」に変えてしまう。

この3つはlintでしか報告されず、コードを書き換えない。書き換えるべきでもない。正しい直し方（guard let、do/catch、型の変更）は文脈によって変わるからである。

代償として、避けられない報告がいくらか出る。UIKitの@IBOutletは設計上、暗黙的アンラップである。Bundle.main.url(forResource:)のような「リソースは必ずappバンドルに入っている」呼び出しも!なしで書くのは難しい。その場合は一行のコメントで個別に免除する。

1
// swift-format-ignore: NeverUseImplicitlyUnwrappedOptionals
2
var label: String!

この指示は直後の宣言にだけ効き、それ以降の宣言は通常どおり検査される。ファイル全体を免除するには// swift-format-ignore-fileを使う。

NoEmptyLinesOpeningClosingBraces（書き換える）#

1
struct S {
2

3
  var x = 1
4

5
}

有効にした理由： 波括弧に接した空行は何のグループも表さない。改行キーを押した痕跡でしかない。

OmitExplicitReturns（書き換える）#

1
func double(_ x: Int) -> Int {
2
  return x * 2
3
  x * 2
4
}
5
var squared: Int {
6
  return 4
7
  4
8
}

有効にした理由： SwiftUIのbodyも多くの計算プロパティも単一の式である。言語が省略を許している以上、各自の習慣に任せるのではなくツールに統一して省かせる。後述のデフォルトルールUseSingleLinePropertyGetter（余分なget { }を取り除く）と組み合わせると、計算プロパティは式そのものだけまで簡略化される。

これについては少し疑いを残している。returnを省くと、単一式の関数とクロージャが視覚的に区別しにくくなる。ただしSwiftUIのコードでは利点のほうが大きい。

UseEarlyExits（書き換える）#

1
func f(_ x: Int?) {
2
  if let x = x {
3
    print(x)
4
  } else {
5
  guard let x = x else {
6
    return
7
  }
8
  print(x)
9
  print("done")
10
}

有効にした理由： guardは「条件を満たさなければ抜ける」という意図を先頭に置き、主な処理を最も外側のインデントに残す。Swiftでは珍しい、ツールが確実に実行できる意味レベルの書き換えである。

else節が単一の脱出文だけの場合しか扱わないので、複雑な分岐が勝手に変えられることはない。

UseWhereClausesInForLoops（書き換える）#

1
func f(_ xs: [Int]) {
2
  for x in xs {
3
    if x > 0 {
4
      print(x)
5
    }
6
  for x in xs where x > 0 {
7
    print(x)
8
  }
9
}

有効にした理由： インデントが1段減り、whereが「絞り込み」と「処理」を構文レベルで分けてくれる。

ValidateDocumentationComments（報告のみ）#

ドキュメントコメントの引数リストが実際のシグネチャと一致しているか検査する。

1
/// Returns the sum.
2
///
3
/// - Parameters:
4
///   - a: first
5
///   - c: wrong name
6
/// - Returns: the sum
7
func add(a: Int, b: Int) -> Int { a + b }

1
warning: [ValidateDocumentationComments]
2
change the parameters of the documentation of 'add' to match its parameters

有効にした理由： ドキュメントコメントとシグネチャのずれは、最も気づきにくい種類の誤りである。コンパイルにも実行にも影響せず、次にコードを読む人（たいてい自分）を誤解させるだけだからである。

書き換える側#

DoNotUseSemicolons —— セミコロンを改行にする。

1
let a = 1; let b = 2;
2
let a = 1
3
let b = 2

FullyIndirectEnum —— すべてのcaseがindirectならenum側に引き上げる。

1
enum Tree {
2
  indirect case node(Tree, Tree)
3
  indirect case leaf(Tree)
4
indirect enum Tree {
5
  case node(Tree, Tree)
6
  case leaf(Tree)
7
}

GroupNumericLiterals —— 長い数値リテラルにアンダースコアの区切りを入れる。

1
let big = 1000000
2
let hex = 0xFFFFFFFF
3
let big = 1_000_000
4
let hex = 0xFFFF_FFFF
5
let bin = 0b11110000

最後の行が変わっていないことに注意。8桁の2進数リテラルは閾値の内側である。

NoAccessLevelOnExtensionDeclaration —— アクセスレベルをextensionからメンバーへ移す。

1
public extension String {
2
  func shout() -> String { uppercased() }
3
extension String {
4
  public func shout() -> String { uppercased() }
5
}

NoAssignmentInExpressions —— 式の中の代入を独立した文に分ける。

1
func f() -> Int {
2
  var x = 0
3
  return x = 5
4
  x = 5
5
  return
6
}

（この例は元のコードからして怪しく、書き換えた結果もコンパイルできるとは限らない。このルールの価値は、その行を見直させることにある。）

NoCasesWithOnlyFallthrough —— fallthroughだけのcaseを統合する。

1
case 1:
2
  fallthrough
3
case 2:
4
case 1, 2:
5
  print("small")

NoEmptyTrailingClosureParentheses —— トレイリングクロージャの前の空の括弧。

1
UIView.animate() {
2
UIView.animate {

NoLabelsInCasePatterns —— caseパターン内の余分なラベル。

1
case .a(x: let x, y: let y):
2
case .a(let x, let y):

NoParensAroundConditions —— 条件式を囲む括弧。

1
if (x > 0) {
2
if x > 0 {
3
while (x < 10) { break }
4
while x < 10 { break }

NoVoidReturnOnFunctionSignature —— 関数シグネチャ上の明示的な-> Void。

1
func f() -> Void {}
2
func g() -> () {}
3
func f() {}
4
func g() {}

ReturnVoidInsteadOfEmptyTuple —— クロージャ型の()をVoidにする。

1
let handler: (Int) -> () = { _ in }
2
let handler: (Int) -> Void = { _ in }

前のルールと向きが逆だが矛盾はしていない。関数シグネチャ上の戻り値の型は削除し、型注釈の中ではVoidと書く。

OneCasePerLine —— 関連値や生の値を持つcaseを独立した行にする。

1
enum E {
2
  case a, b, c(Int)
3
  case d = 1, e = 2
4
  case a, b
5
  case c(Int)
6
  case d = 1
7
  case e = 2
8
}

値を持たないcase a, bは1行のまま残ることに注意。

OneVariableDeclarationPerLine —— 1行に1つの変数。

1
let a = 1, b = 2, c = 3
2
let a = 1
3
let b = 2
4
let c = 3

UseExplicitNilCheckInConditions —— 束縛を捨てるif let _をnil比較にする。

1
if let _ = x {
2
if x != nil {

UseLetInEveryBoundCaseVariable —— case let .a(x, y)を各束縛にletを書く形にする。

1
case let .a(x, y):
2
case .a(let x, let y):

UseShorthandTypeNames —— ジェネリクス表記を短縮形にする。

1
var a: Array<Int> = []
2
var b: Optional<String> = nil
3
var c: Dictionary<String, Int> = [:]
4
var a: [Int] = []
5
var b: String? = nil
6
var c: [String: Int] = [:]

UseSingleLinePropertyGetter —— 読み取り専用プロパティの余分なget { }。

1
var x: Int {
2
  get {
3
    return 1
4
  }
5
  return 1
6
}

UseTripleSlashForDocumentationComments —— ブロックコメントのドキュメントを///にする。

1
/**
2
 * A documented function.
3
 */
4
/// A documented function.
5
func f() {}

FileScopedDeclarationPrivacyとOrderedImportsは、それぞれ設定項目を持つため前述した。

報告のみ#

コードを変更せず、lintで報告するだけのルールである。

このグループには特に意見はない。報告される内容はどれも実際の問題である。一つだけ触れておくとReplaceForEachWithForLoopで、forEachの中ではbreakもcontinueも使えず、returnの意味も直感と違う（そのクロージャ呼び出しを抜けるだけである）ので、for-inのほうが確かに安全である。