Merge pull request jarinosuke#5 from niwatako/niwatako/master

jarinosuke · web-flow · commit bd5c551fe537 · 2016-07-26T16:02:24.000+09:00
Update to github/swift-style-guide@b1b2914
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,3 +1,8 @@
+This guide is primarily intended to be _descriptive_, detailing the usage
+that Swift developers at GitHub have arrived at in cases of disagreement.
+Consider whether a proposed addition would make more sense in a fork used
+by your projects/organization instead.
+
 If you want to suggest a change or addition that will help accomplish
 [the goals](README.md) of this style guide, please open a pull request that:
 
diff --git a/README.md b/README.md
@@ -28,12 +28,35 @@ Use `let foo = …` over `var foo = …` wherever possible (and when in doubt).
 
 _Rationale:_ The intent and meaning of both keywords is clear, but *let-by-default* results in safer and clearer code.
 
-A `let`-binding guarantees and *clearly signals to the programmer* that its value is supposed to and will never change. Subsequent code can thus make stronger assumptions about its usage.
+A `let`-binding guarantees and *clearly signals to the programmer* that its value will never change. Subsequent code can thus make stronger assumptions about its usage.
 
 It becomes easier to reason about code. Had you used `var` while still making the assumption that the value never changed, you would have to manually check that.
 
 Accordingly, whenever you see a `var` identifier being used, assume that it will change and ask yourself why.
 
+### Return and break early
+
+When you have to meet certain criteria to continue execution, try to exit early. So, instead of this:
+
+```swift
+if n.isNumber {
+    // Use n here
+} else {
+    return
+}
+```
+
+use this:
+```swift
+guard n.isNumber else {
+    return
+}
+// Use n here
+```
+
+You can also do it with `if` statement, but using `guard` is prefered, because `guard` statement without `return`, `break` or `continue` produces a compile-time error, so exit is guaranteed.
+
+
 #### Avoid Using Force-Unwrapping of Optionals
 
 If you have an identifier `foo` of type `FooType?` or `FooType!`, don't force-unwrap it to get to the underlying value (`foo!`) if possible.
@@ -59,7 +82,7 @@ _Rationale:_ Explicit `if let`-binding of optionals results in safer code. Force
 
 #### Avoid Using Implicitly Unwrapped Optionals
 
-Where possible, use `let foo: FooType?` instead of `let foo: FooType!` if foo may be nil (Note that in general, `?` can be used instead of `!`).
+Where possible, use `let foo: FooType?` instead of `let foo: FooType!` if `foo` may be nil (Note that in general, `?` can be used instead of `!`).
 
 _Rationale:_ Explicit optionals result in safer code. Implicitly unwrapped optionals have the potential of crashing at runtime.
 
@@ -190,7 +213,7 @@ class Vehicle {
     }
 
     func maximumTotalTirePressure(pressurePerWheel: Float) -> Float {
-        return pressurePerWheel * numberOfWheels
+        return pressurePerWheel * Float(numberOfWheels)
     }
 }
 
@@ -215,7 +238,7 @@ protocol Vehicle {
 }
 
 func maximumTotalTirePressure(vehicle: Vehicle, pressurePerWheel: Float) -> Float {
-    return pressurePerWheel * vehicle.numberOfWheels
+    return pressurePerWheel * Float(vehicle.numberOfWheels)
 }
 
 struct Bicycle: Vehicle {
@@ -284,3 +307,5 @@ _Rationale:_ Operators consist of punctuation characters, which can make them di
 
 * [中文版](https://github.com/Artwalk/swift-style-guide/blob/master/README_CN.md)
 * [日本語版](README_JP.md)
+* [한국어판](https://github.com/minsOne/swift-style-guide/blob/master/README_KR.md)
+* [Versión en Español](https://github.com/antoniosejas/swift-style-guide/blob/spanish/README-ES.md)
diff --git a/README_JP.md b/README_JP.md
@@ -28,14 +28,37 @@ Swift コーディング規約
 
 _理由:_ 二つのキーワードの意図と意味は明瞭ですが、*デフォルトでlet*を使うことは、より安全でより明確なコードになります。
 
-`let`宣言は、その変数の値が変わらないとを想定されていて、かつ実際に変わらない
-ことを保証すると同時に、それを*プログラマに明確に伝えます*。そのため、その後に続くコードにおいて、その変数の用途を推測しやすくなります。
+`let`宣言は、その変数の値が変わらないことを保証すると同時に、それを*プログラマに明確に伝えます*。そのため、その後に続くコードにおいて、その変数の用途を推測しやすくなります。
 
 コードを論理的に理解するのがより簡単になります。値が決して変わらないと考えているにもかかわらず`var`を使うと、本当に値が変わらないかどうかを手動でチェックしなければいけません。
 
 この方法に従うと結果的に、`var`宣言が使われているのを発見した時は必ず、その値が変わり得ると推測したり、その理由を考えることができます。
 
 
+#### Return と break を早期に行う
+
+実行を継続するには基準を満たす必要があるような場合は、なるべく早期にコードブロックから抜け出すようにしましょう。
+
+その際、以下のようにする代わりに:
+```swift
+if n.isNumber {
+    // Use n here
+} else {
+    return
+}
+```
+
+以下のように書きましょう:
+```swift
+guard n.isNumber else {
+    return
+}
+// Use n here
+```
+
+If文でも同じことが可能ですが、`guard`を使うことが推奨されます。`guard`文では`return`や`break`、`continue`が無いとコンパイルエラーとなるため、コードブロックから抜け出すことが保証されるからです。
+
+
 #### オプショナル型の開示指定は避ける
 
 `FooType?`もしくは`FooType!`型の変数`foo`がある場合、そこにある`foo!`を得ようとして`foo`に対して開示指定を行うのは可能な限り避けないといけません。
@@ -188,7 +211,7 @@ class Vehicle {
     }
 
     func maximumTotalTirePressure(pressurePerWheel: Float) -> Float {
-        return pressurePerWheel * numberOfWheels
+        return pressurePerWheel * Float(numberOfWheels)
     }
 }
 
@@ -213,7 +236,7 @@ protocol Vehicle {
 }
 
 func maximumTotalTirePressure(vehicle: Vehicle, pressurePerWheel: Float) -> Float {
-    return pressurePerWheel * vehicle.numberOfWheels
+    return pressurePerWheel * Float(vehicle.numberOfWheels)
 }
 
 struct Bicycle: Vehicle {
@@ -282,3 +305,6 @@ _理由:_ オペレータは記号でできており、それらが型や値の
 #### 翻訳
 
 * [中文版](https://github.com/Artwalk/swift-style-guide/blob/master/README_CN.md)
+* [日本語版](README_JP.md)
+* [한국어판](https://github.com/minsOne/swift-style-guide/blob/master/README_KR.md)
+* [Versión en Español](https://github.com/antoniosejas/swift-style-guide/blob/spanish/README-ES.md)
