Swift2 スタイルガイドライン はどれが良いの?
Swift2のスタイルガイドラインについて調べている時に、 Swift用の静的解析ツール Tailor というものを見つけた。 まずは、Tailor のチェックルールを自分用スタイルガイドラインにしたいと思う。
README.md によると以下のスタイルガイドラインに対応しているとのこと。
The Swift Programming Language : The Swift Programming Language (Swift 2.1): About Swift
GitHub : github/swift-style-guide: Style guide & cod... - GitHub
Ray Wunderlich : raywenderlich/swift-style-guide - GitHub (和訳 : swift-style-guide/ja_style_guide.md at master · dekatotoro/swift-style-guide · GitHub)
Coursera style guides : coursera/swift-style-guide - GitHub
また、チェックルールを理解するため、以下に簡単にまとめた。(訳は適当。詳細は Tailor のチェックルール を参照。)
Naming
[upper-camel-case] UpperCamelCase naming
class, enum, enum の値, structおよびprotocolの名前はUpperCamelCase(パスカルケース)命名規則に従うべき。
[lower-camel-case] lowerCamelCase naming
[constant-naming] Constant naming
グローバル定数はUpperCamelCaseかlowerCamelCaseのいずれかの命名規則に従うべき。 ローカル定数はlowerCamelCaseの命名規則に従うべき。
[constant-k-prefix] Flag "k-prefixed" constants
定数名にプレフィックスkは付与しない。
Whitespace
[arrow-whitespace] Flag arrows that are not space delimited
"->" の前後をスペース1文字で囲む。
[angle-bracket-whitespace] Check whitespace in and around angular brackets
"<"の前後と、">"の前にはスペースを入れない。
[colon-whitespace] Flag incorrect whitespace around colons
":"を以下で使用する場合には、":"の前にスペースは入れずに、":"の後にスペース1文字を入れる。
- var, class, struct, protocol, extension, funcおよびtuple宣言
- DictionaryのリテラルとDictionaryの型宣言
- case文
ただし、三項演算子の場合は、":"の前後をスペース1文字で囲む。
[comma-whitespace] Flag commas that are not left associated
ジェネリックおよび型継承時の場合、","の前にはスペースは入れずに ","の後にスペース1文字を入れる。
[operator-whitespace] Flag operators that are not space delimited (only in operator declarations)
[leading-whitespace] Flag leading whitespace in a file
Verify that source files begin with a non-whitespace character. ソースファイルの先頭は非空白文字で開始するべき。
[terminating-newline] Single newline at end of source file
ソースファイルは1個の"\n"で終了すべき。0個や1個以上で終了してはいけない。
[parentheses-whitespace] Check whitespace in and around parenthesis
"("の前後と、")"の前にはスペースを入れない。
[trailing-whitespace] Flag trailing whitespace
行末にスペースを入れない。
[comment-whitespace] Comment whitespace checks
コメント開始シンボル(/, //, * および /**)の後にはスペースを1文字以上入れる。 コメント終了シンボル(*)の前には、スペースを1文字以上入れる。
[function-whitespace] Blank lines around functions
全ての関数およびメソッド宣言の前後には空行を入れる。 ただし、ファイルの先頭での宣言やファイルの最後での宣言の場合は、それぞれ宣言後、宣言前に空行を入れる。 関数およびメソッド宣言直前のコメントは宣言の一部とみなす。(コメントと宣言の間には空行を入れない。)
Length
ファイルおよび型定義の行数制限
[max-class-length]
クラス定義の行数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[max-closure-length]
クロージャー定義の行数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[max-file-length]
ファイル内の行数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[max-function-length]
関数定義の行数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[max-struct-length]
構造体定義の行数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
行や型名の文字数の制限
[max-line-length]
行の文字数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[max-name-length]
classes, enums, enumcases, structs, protocols, elements, functions, labels, setters, typealiases, types, variables および constants 名の文字数の上限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
[min-name-length]
classes, enums, enumcases, structs, protocols, elements, functions, labels, setters, typealiases, types, variables および constants 名の文字数の下限を制限する。(tailorのコマンドラインオプションで明示的に指定した場合のみ有効になる。)
Others
[redundant-parentheses] Flag redundant parentheses
制御構文(if, else if, switch, for, while, repeat-whileおよびguard文)、例外補足(throwおよびdo/catch文)、および初期化子(array, dictionary, initializer patterns???)の場合、 括弧で囲むべきではない。 さらに、パラメータがなく末尾がクロージャーであるメソッドを呼び出す場合、メソッド名の後に空の括弧を付けるべきでない。
[brace-style] One true brace style
中括弧は、"the one true brace style"に従う。
[forced-type-cast] Flag force casts
コンパイル時にキャストできるか確定できないため、"as!"の使用を避ける。 キャスト失敗した場合はランタイムエラーが発行される。 より安全な"as?"でキャストするべき。
[multiple-imports] One import per line
1行で複数のimport文は書かない。
[terminating-semicolon] Flag semicolon terminated statements
Swift does not require a semicolon after each statement in your code unless you wish to combine multiple statements on a single line. 複数文を1行にまとめる場合を除き、Swiftは文の末尾にセミコロンを必要としない。 複数文をセミコロンを使って1行に書いてはいけない。
[todo-syntax] Verify TODO syntax
TODOコメントは、ネストのない1行コメントに単独で定義されるべき。 TODOコメントは、<TODO: description> および <TODO(developer-name): description> 形式で記載するべき。 descriptionのない空のTODOコメントもダメ。 ("/"ではじまるドキュメンテーション用コメントにはTODOは記載するべきではない。)