SwiftLintのRules一覧（2018年3月最新版）

SwiftLintのRulesについてまとめました。
なお、ルール一覧については下記コマンドにて確認が可能です。

swiftlint rules

また、この他、GitHub上にはRules.mdも存在するので、そちらを確認すると最新のルール一覧が確認可能です。
あまりにも量が多いので、ここではopt-inのRulesについてのみまとめます。

追記

ここに記載の内容は2018年時点のもので古いです。
最新のルールは2023年時点で以下のURLにて公開されているのでこちらを参照してください。
https://realm.github.io/SwiftLint/rule-directory.html

ルール一覧

array_init

Rules.mdのArray Initの項
sequenceからArrayへの変換をする際に、seq.map { $0 }ではなくArray(seq)を使用する方が望ましいというもの。

attributes

Rules.mdのattributesの項
@objcや@IBOutletなどの属性(attributes)はvarやimportに対するものの場合は同じ行に配置し、型や関数に対するものの場合は別の行に配置すべきというもの。

closure_end_indentation

Rules.mdのClosure End Indentationの項
クロージャーの最後の閉じ括弧はクロージャーの先頭の行のインデントに揃えるべきというもの。

closure_spacing

Rules.mdのClosure Spacingの項
クロージャーの式を記述する際に、中括弧の中の始まりと終わりの部分に１つだけスペースを入れるべきというもの。

conditional_returns_on_newline

Rules.mdのConditional Returns on Newlineの項
条件文は新しい行でreturnすべきというもの。

// 正しい
guard true else {
  return true
}
// 警告が出る
guard true else { return true }

contains_over_first_not_nil

Rules.mdのContains over first not nilの項
first(where:) != nilよりもcontainsの方が望ましいというもの。

// 正しい
let first = myList.first(where: { $0 % 2 == 0 })
// 警告が出る
myList.first { $0 % 2 == 0 } != nil

discouraged_object_literal

Rules.mdのDiscouraged Object Literalの項
Object Literalよりもinitializersを使っての初期化の方が望ましいというもの。

// 正しい
let image = UIImage(named: aVariable)
// 警告が出る
let image = #imageLiteral(resourceName: "image.jpg")

discouraged_optional_boolean

Rules.mdのDiscouraged Optional Booleanの項
OptionalのBoolean（Bool?）を使用するよりも、通常のBooleanを使用する方が望ましいというもの。

empty_count

Rules.mdのEmpty Countの項
配列のcountが0かどうかを比較する場合は、isEmptyを使用する方が良いというもの。

explicit_acl

Rules.mdのExplicit ACLの項
全ての宣言にAccess Control Levelのキーワード（public/privateなど）を記述すべきというもの。frameworkを提供する場合などに記述があると分かりやすいというのがその理由。

explicit_enum_raw_value

Rules.mdのExplicit Enum Raw Valueの項
enumには明示的に値を指定しておく方が望ましいというもの。

explicit_init

Rules.mdのExplicit Initの項
明示的に.init()を呼ばない方が良いというもの。

explicit_top_level_acl

Rules.mdのExplicit Top Level ACLの項
最上位の宣言では、アクセス制御レベル（public/privateなど）を明示的に指定する必要があるというもの。

explicit_type_interface

Rules.mdのExplicit Type Interfaceの項
プロパティには明示的に型を記述すべきというもの。

extension_access_modifier

Rules.mdのExtension Access Modifierの項
extensionのアクセス修飾子を使う方が望ましいというもの。ちょっと分かりにくいが、適切にextensionにアクセス修飾子（public/privateなど）が付与されていれば警告は出ないというもの。

// 正しい
extension Foo {
   private var bar: Int { return 1 }
   public var baz: Int { return 1 }
}
public extension Foo {
   var bar: Int { return 1 }
   var baz: Int { return 1 }
}
// 警告が出る
extension Foo {
   public var bar: Int { return 1 }
   public var baz: Int { return 1 }
}

fatal_error_message

Rules.mdのFatal Error Messageの項
fatalErrorを使用するときはfatalError("message")のように何かしら文字列を入れるべきというもの。

file_header

Rules.mdのFile Headerの項
ファイルのヘッダコメントは指定したプロジェクトパターンに合致しているか、もしくは除去されているべきというもの。
SwiftLintの設定ファイル(.swiftlint.yml)でそのプロジェクトパターンが指定できます（設定例）。

first_where

Rules.mdのFirst Whereの項
配列で最初にマッチした要素を取得したい場合、.filter { }.firstではなく.first(where:)を使用するのが望ましいというもの。

force_unwrapping

Rules.mdのForce Unwrappingの項
強制アンラップは使用しない方がいいというもの。ただしIBOutletなどでは警告は入らず、dict["abc"]↓.bar("B")などのアンラップに対して警告が出る。

implicit_return

Rules.mdのImplicit Returnの項
クロージャーでは暗黙のreturnを活用すべきというもの。

// 正しい
foo.map { $0 + 1 }
// 警告がでる
foo.map { value in
  ↓return value + 1
}

implicitly_unwrapped_optional

Rules.mdのImplicitly Unwrapped Optionalの項
可能な限り暗黙的なアンラップ（let label: UILabel!など）は避けるべきというもの。

joined_default_parameter

Rules.mdのJoined Default Parameterの項
bar.joined(↓separator: "")のようなデフォルトの区切り文字明示は避けてbar.joined(separator: ",")などのようにすべきというもの。

let_var_whitespace

Rules.mdのVariable Declaration Whitespaceの項
let/varと他の式の間には空行を設けるべきというもの。

literal_expression_end_indentation

Rules.mdのLiteral Expression End Indentationの項
array/dictionaryのリテラルのインデントは最初と最後を揃えるべきというもの。

multiline_arguments

Rules.mdのMultiline Argumentsの項
引数は全て同じ行に書くか、もしくは行を分けるなら全ての引数１つ１つで改行すべきというもの。

multiline_parameters

Rules.mdのMultiline Parametersの項
function/methodのパラメータは全て行に書くか、もしくは行を分けるなら全てのパラメータ１つ１つで改行すべきというもの。ちなみに、引数(arguments)とパラメータ(parameters)の違いはこちらにもあるようにfunctionの定義が書いてある箇所はパラメータで、それを呼び出す場所に書いてあるのは引数。すなわち、パラメータは関数内で使用されるもので、引数は関数が呼び出されたときに渡される値のこと。

nimble_operator

Rules.mdのNimble Operatorの項
Prefer Nimble operator overloads over free matcher functions.（Nimble演算子のoverloadsはfree matcher関数よりも好ましい）が元の文章なのだけど、いまいちピンとこない。Nimbleというテストで使用するマッチャーにおいて、expect(12).toNot(equal(10))のような形式で書くよりもexpect(10) > 2のようにシンプルで書く方が望ましいというもの。

no_extension_access_modifier

Rules.mdのNo Extension Access Modifierの項
extension_access_modifierの逆。extensionにアクセス修飾子を付けていると警告が発生する。

no_grouping_extension

Rules.mdのNo Grouping Extensionの項
同じソースファイル内でコードをまとめるために拡張子を使用すべきではないというもの。説明が少し分かりにくいが、同じファイル内でstructやenumなどのextensionが記述されていると警告が出る。

number_separator

Rules.mdのNumber Separatorの項
数値を表記する際には1000の単位が明確になる箇所に適切にアンダーバーを使用すべきというもの。1_000_000.000_000_1などは問題なく、1000や10_0などは警告が出る。

object_literal

Rules.mdのObject Literalの項

discouraged_object_literalの逆で、initializersよりもObject Literalを使っての初期化の方が望ましいというもの。

// 正しい
let image = #imageLiteral(resourceName: "image.jpg")
// 警告が出る
let image = UIImage(named: aVariable)

operator_usage_whitespace

Rules.mdのOperator Usage Whitespaceの項
演算子は前後に1つスペースを設けるべきというもの。

overridden_super_call

Rules.mdのOverridden methods call superの項
overrideする場合はsuperのメソッドを呼ぶべきというもの。

override_in_extension

Rules.mdのOverride in Extensionの項
extensionでvarなどをoverrideすべきでないというもの。

pattern_matching_keywords

Rules.mdのPattern Matching Keywordsの項
直訳すると、タプルからキーワードを移動することにより、複数のパターンマッチングバインディングを組み合わせることができますとのこと。いまいちイメージが付かないので、警告の出るパターンと正しいパターンで比較すると、以下のようになります。

// 正しい
switch foo {
    case let (x, y): break
}
switch foo {
    case .foo(let x): break
}
switch foo {
    case let .foo(x, y): break
}
switch foo {
    case .foo(let x), .bar(let x): break
}
// 警告が出る
switch foo {
    case (↓let x,  ↓let y): break
}
switch foo {
    case .foo(↓let x, ↓let y): break
}
switch foo {
    case (.yamlParsing(↓let x), .yamlParsing(↓let y)): break
}
switch foo {
    case (↓var x,  ↓var y): break
}

prefixed_toplevel_constant

Rules.mdのPrefixed Top-Level Constantの項
トップレベルの定数はk始まりにすべきというもの。古いフレームワークなどではよく見かける。

private_action

Rules.mdのPrivate Actionsの項
IBActionsはprivateにすべきというもの。

private_outlet

Rules.mdのPrivate Outletsの項
IBOutletsはprivateにすべきというもの。

prohibited_super_call

Rules.mdのProhibited calls to superの項
superメソッドを呼ぶべきではないというもの。overridden_super_callとは排他の関係。

quick_discouraged_call

Rules.mdのQuick Discouraged Callの項
詳細はこのissueを参照のこと。describeとcontextブロック内でのメソッド呼び出しとオブジェクト初期化が有害である可能性があるため、警告が出るもの。（このissueも合わせて参照のこと）

quick_discouraged_focused_test

Rules.mdのQuick Discouraged Focused Testの項
(fdescribe, fcontext, fitを使用した)フォーカステストを使用していない場合に警告が出るもの。このissueに記載されている通り、TDDを行う場合などによく利用される（詳細はissueかRules.mdを参照のこと）。

quick_discouraged_pending_test

Rules.mdのQuick Discouraged Pending Testの項
保留中のテストに対して警告を発する。issue:#1909を参照のこと。

redundant_nil_coalescing

Rules.mdのRedundant Nil Coalescingの項
無駄なnil結合演算子に警告が出るもの。Int?型のvalに対してval ?? nilはnilならnilを入れるという意味のないものになるため警告が出る。

required_enum_case

Rules.mdのRequired Enum Caseの項
列挙型がプロトコルに準拠する場合、特定のケースの実装が必要であるというもの。

single_test_class

Rules.mdのSingle Test Classの項
テストファイルには、QuickSpecまたはXCTestCaseクラスが１つだけ含まれている必要があるというもの。

sorted_first_last

Rules.mdのMin or Max over Sorted First or Lastの項
sorted().firstまたはsorted().lastを使用するより、min()またはmax()を使用する方が望ましいというもの。

sorted_imports

Rules.mdのSorted Importsの項
importはソートされているべきというもの。

strict_fileprivate

Rules.mdのStrict fileprivateの項
fileprivateは使用すべきではないというもの。

switch_case_on_newline

Rules.mdのSwitch Case on Newlineの項
switch文のcase *:のあとは必ず改行すべきというもの。

trailing_closure

Rules.mdのTrailing Closureの項
可能であれば、末尾のクロージャ構文を使用すべきというもの。

unneeded_parentheses_in_closure_argument

Rules.mdのUnneeded Parentheses in Closure Argumentの項
クロージャ引数を宣言するときは、括弧は必要ないので書かないようにすべきというもの。

vertical_parameter_alignment_on_call

Rules.mdのVertical Parameter Alignment On Callの項
関数のパラメータの記述において、改行を挟む場合はパラメータの先頭位置を揃えるべきというもの。

yoda_condition

Rules.mdのYoda condition ruleの項
定数と変数の比較において、変数は左側に、定数は右側に配置すべきというもの。